PESTO: An Integrated Query/Browser for Object Databases - CiteSeerX

PESTO: An Integrated Query/Browser for Object Databases Michael Careyy

Laura Haasy

Vivekananda Magantyz

John Williamsy

yIBM Almaden Research

Center, San Jose, CA zComputer Sciences Department, University of Wisconsin, Madison, WI fcarey, laura, [email protected] [email protected]

Abstract

This paper describes the design and implementation of PESTO (Portable Explorer of STructured Objects), an integrated user interface that supports browsing and querying of object databases. Like other object browsers, PESTO allows users to navigate in a hypertext-like fashion, following the relationships that exist among objects. In addition, PESTO allows users to formulate object queries through a unique, integrated query paradigm that presents querying as a natural extension of browsing; we call this paradigm \query-in-place." PESTO's query facilities are quite powerful, including support for basic query operations such as simple selections, value-based joins, universal quanti cation, negation, and complex predicates, as well as object-oriented queries including path predicates (implicit joins), queries over nested sets, ltered sets, and method invocation. PESTO can be ported with relative ease to any objectoriented database system supporting a high-level query language, and its implementation is extensible in the sense that PESTO provides hooks that allow specialized predicate formation and display tools to be added to the system for important new data types (e.g., images or text).

1 Introduction The insertion of object technology into the marketplace is one of the major trends in the database industry today. A number of startup companies are selling object-oriented database (OODB) systems based on C++ or Smalltalk. Moreover, a growing number of companies are oering objectrelational database products. These extend the relational model with object-oriented features (e.g., OIDs, inter-object references, and support for objects with embedded collections such as sets and lists). Most of today's relational database products are also planning to add these features. Finally, several vendors are now marketing object-oriented \middleware" products that can wrap a relational database, providing an object-oriented view of (and programmatic access to) relational data. As a result of all this activity, there is a growing need for good user interfaces for accessing object-oriented data { regardless of whether it is stored in an OODB system, an object-relational database system, or materialized via wrapper technology. 1

The Garlic project at the IBM Almaden Research Center [Care95] is developing a system and associated tools for managing large quantities of heterogeneous multimedia information. The goal of Garlic is to permit both traditional and multimedia data residing in a variety of existing data repositories (including relational databases, document managers, image repositories, and les) to be presented to application developers and end users via a uni ed, object-oriented schema. The heterogeneous data can then be queried uniformly and manipulated using an object-oriented dialect of SQL. One component of this project, which is joint work between IBM Almaden and the University of Wisconsin, is the development of a graphical user interface called PESTO (Portable Explorer of STructured Objects). We refer to the PESTO interface as a query/browser, as it marries navigational object browsing with declarative querying; it integrates browsing and querying via a \query-in-place" paradigm that provides a powerful yet natural user interface for exploring the contents of object databases. The rest of this paper describes the design of PESTO. Like other object database browsers, PESTO provides a hypertext-like navigational capability that enables users to navigate the relationships between database objects. In addition, PESTO enables users to query the contents of an object database without having to write (or even look at) object queries; querying is treated as a natural and direct extension of browsing. As a result, the query facilities of PESTO are intuitive yet powerful, supporting basic query capabilities such as simple selections, value-based joins, negation, and disjunction; they also enable complex object queries involving structural predicates and universal quanti cation to be expressed in a very intuitive manner. While PESTO has been developed as part of the Garlic project, it can be ported to any system that supports an object-based data model and a declarative query interface. In fact, in addition to Garlic, it currently runs on top of a SQL-based query interface to the ObjectStore database system, described in [Kier95], and this version of PESTO was used to generate the gures and queries shown throughout the paper. The remainder of this paper is organized as follows. Section 2 brie y reviews related work on user interfaces and explains how PESTO diers from existing database browsing and query tools. Section 3 describes the basic look and feel of PESTO, conveying its integrated approach to browsing and querying through the use of several examples; PESTO's support for iterative query re nement is also described brie y. Section 4 then discusses PESTO's query capabilities more technically, focusing on PESTO's support for complex OODB queries and on the semantics and the limitations of PESTO as a query language. Section 5 brie y highlights a few interesting details of PESTO's current implementation, including its portability features and the way that new data types (such as images) and associated predicate formation tools can be added. Finally, Section 6 summarizes the paper and discusses the current status of PESTO.

2 Related Work To set the stage for describing PESTO, we brie y review related work on graphical database interfaces, including both commercial relational interfaces and interfaces to databases based on semantic and object-oriented data models. We then highlight the main ways in which PESTO 2

diers from these interfaces.

2.1 Commercial Interfaces Visual interfaces to databases have come to be viewed as important tools in the commercial database world. Virtually all relational database system vendors oer such interfaces for their systems, and a number of other vendors sell graphical query and application development tools that will run against multiple relational database engines. The existing commercial products have been in uenced by early research in this area, including eorts such as Timber [Ston82], FORMANAGER [Yao84], FADS [Rowe82], and of course, the seminal work on QBE [Zloo77]. However, commercial relational front-ends such as Access, Paradox, Visualizer, BusinessObjects, and FindOut! have long since surpassed this early work, due to the ready availability of workstations and personal computers with bitmapped displays and mice, as well as windowing systems and user interface toolkits, all of which have dramatically improved both the ease of development and the ease of use of graphical database user interfaces. Most commercial relational front-ends allow users to choose among several \views" of their databases. For example, Access provides four: a datasheet view that displays data from a table or query in a tabular format, a form view that displays a single record at a time, a query view in which the user can form a new query or edit an old one, and a report view in which data is formatted, usually for printing. These views are each separate from one another; for example, the query view, even in Paradox { which provides an excellent implementation of the Query-by-Example [Zloo77] paradigm { is totally separate from the data views that are oered. Thus, a strong distinction is made in these products between the act of query formation and the act of browsing a query's result set. This is quite dierent from the query-in-place approach that PESTO takes; this dierence becomes particularly important in the world of object databases, as Section 3 will show. Some commercial relational front-ends are beginning to provide their users with the ability to specify the \business objects" that they want to work with. Good examples of such systems are BusinessObjects 3.1 and Open Data's FindOut!. \Business objects" are typically just businessrelevant views of the underlying data that are set up by a database administrator to make browsing and querying easier for end users; they should not be confused with the kinds of objects that object database systems are intended to manage. The closest these interfaces come to true object support is a feature of FindOut!, which uses the relationships de ned among the object views to allow users to do simple navigation among their objects. However, even the Findout! interface provides no support for the more powerful kinds of object queries (e.g., queries over nested sets of inter-object references) that PESTO supports. One other signi cant family of interfaces is relevant to PESTO. The hypertext data browsing interfaces of Mosaic and, more recently, Netscape have taken the world by storm over the past few years. This is due in part to the natural object browsing paradigm that they support and in part to the interesting world to which they provide access. However, these interfaces are designed for an environment without a schema, i.e., for a world where the data model consists of objects and 3

(largely) untyped inter-object references; thus, these interfaces do not oer object query facilities. One of our goals in developing PESTO has been to provide a similarly friendly browsing interface, also based on hypertext-style navigation, and to augment this interface with an equally natural paradigm for integrating querying and query re nement with browsing.

2.2 Related Research In general, user interfaces have been somewhat neglected as a database research topic [Ston89, Ston93]. Still, a fair-sized body of work exists in this area; a comprehensive survey and taxonomy of graphical user interfaces for database systems can be found in [Bati91]. Aside from the early work on graphical interfaces for relational data, most of the work in the database research community has focused on the design of interfaces for databases based on richer data models such as E-R, semantic, and modern object-oriented data models. Visual interfaces for database browsing are very attractive for systems based on richer data models, as such models make explicit the relationships between data objects in the database. Good examples of visual browsers that have been developed for such data models include KIVIEW [Motr88], Databrowse [Catt88], LID [Fogg84], and OdeView [Agra90]. The KIVIEW design, in particular, introduced the notion of synchronous browsing of related objects; this is a notion that OdeView also emphasized. Synchronous browsing is very important in PESTO as well. Unlike the KIVIEW design, where users explicitly indicate the synchronizing links, PESTO uses an implicit sub-windowing approach that we believe is more convenient and intuitive. Among OODB browsers, PESTO is closest in its browsing style to OdeView; we were heavily in uenced by OdeView's browsing facilities. However, OdeView implements querying and browsing as separate mechanisms, as do virtually all other interfaces that we have seen. Also, OdeView requires the de ner of each object class to write certain display- and query-oriented functions for the class; in contrast, PESTO's object displays and query interactions are fully schema-driven and do not require coding. The interfaces just mentioned support data browsing, i.e., browsing the contents of a database at the instance level. Several other systems have focused on graphical support for browsing of database schemas, including ISIS [Gold85], GUIDE [Wong82], SKI [King84], and OPOSSUM [Habe95]. [Habe94] provides a strong foundation upon which to develop graphical schema browsers. Although schema browsing is clearly important for understanding large databases, as well as locating interesting starting points for data browsing and querying, our work on PESTO has focused on providing intuitive support for exploratory access to the objects in the database. Later we plan to provide support for schema exploration, probably by drawing on related works such as these. Object database interfaces that support graphical formation of queries are typi ed by Pasta-3 [Kunt89] and SNAP [Bryc86] (though the latter could also be classi ed as a schema browser). In SNAP, queries are posed against the database schema to return browsable data, whereas the query formation context for PESTO users is at the data level. Pasta-3 provides a drag-and-drop paradigm for graphically forming and re ning queries. Like Pasta-3, PESTO provides support for query re nement, but PESTO again diers in its integration of querying and browsing; in Pasta4

3, the query and browser windows are maintained separately. We believe that PESTO's support for querying at the instance level, and the elimination of the distinction between query formation and result browsing oered by PESTO's query-in-place notion, oer a signi cantly more intuitive interface for querying and exploring the contents of an object database. In addition to the above, the literature in this area includes various papers whose focus is on tools for building graphical database interfaces; these include FaceKit, Freeform, and DBFace [King87, King89, King92]. Other related eorts include GOOD [Gyss90], which suggested an interesting set of graphical primitives and operations for object data, the work on Proteus [Ande86], and O2Look and ToonMaker from O2 [Borr92]. Finally, there has also been recent work on novel ways of viewing data, e.g., DOODLE [Cruz92] and InfoCrystal [Spoe93]. While interesting, these papers are of less direct relevance to PESTO.

2.3 What's New About PESTO? There are two key dierences between the facilities that PESTO oers and those provided by the interfaces that we have just discussed. One distinguishing aspect of PESTO is that, unlike commercial graphical query tools (which are targeted at relational databases), PESTO is designed for exploring object databases. Thus, PESTO must deal with the complex object structures found in object databases, and it must make it easy to pose queries over such structures. Some of the query interface challenges posed by object data models include the need to support (1) path expressions and method invocations, both for browsing and in predicates, (2) set-valued attributes, including predicates on nested sets and browsing of (possibly restricted versions of) such sets, and (3) continued support for user-speci ed, unanticipated, associative queries (i.e., ad hoc joins). Combining object support with declarative query facilities is an important problem, given the increasing commercial focus on object-oriented and object-relational data models. There are only a few object-oriented database systems that provide declarative query support and even fewer graphical interfaces to these systems. PESTO is unique in its support of advanced object query features, allowing users to express concisely many object queries that would otherwise require complicated and/or convoluted expressions in an object query syntax. Another signi cant contribution of PESTO is its unique integration, at the object level, of support for both querying and browsing within a uni ed graphical user interface. We call this integration query-in-place. Existing graphical query tools make a sharp distinction between query formation and answer set browsing. In contrast, with query-in-place, PESTO allows users to directly restrict the displayed data, much as some relational front-end tools (e.g., table browsers) permit updates in place. Moreover, PESTO generalizes existing notions of ltered browsing by allowing lters to be speci ed (1) in place, on the browse structure, (2) on any level(s) of nested sets, and (3) with arbitrarily complex predicates (including explicit and implicit joins). Consequently, PESTO allows users to simultaneously browse objects at some levels of a complex object structure while querying ( ltering) the objects at other levels. PESTO also provides support for iterative query re nement throughout a PESTO query/browse session. We are unaware of other database query 5

tools that provide such a strong uni cation of querying and browsing.

3 Browsing and Query-In-Place in PESTO In this section we describe PESTO's basic support for synchronized browsing, its notion of queryin-place, and its support for iterative query re nement. We focus here on PESTO's basic facilities, in order to convey its general look and feel; we defer the speci cation and semantics of complex queries to Section 4. First, however, we introduce the schema for a simple object database that will be used in the examples throughout the paper.

3.1 Example Schema Figure 1 shows an object database schema for a hypothetical small (but elitist!) private university that oers both undergraduate and graduate degrees. ODL, the data de nition language of the proposed ODMG-93 standard [Catt94], has been used to express the schema, which we have intentionally kept simple. Student objects contain the usual data about students together with references to their advisors, to one or more majors, and to each of the courses currently being taken. Some students are graduate students, and the corresponding GradStudent objects contain some additional data that only graduate students have. The university also has professors; being an elitist private college, professors are addressed only by their professorial rank and last name. Professor objects also record the professors' area of interest, the year they completed their Ph.D. degree, their picture, their department, the course that they teach, and the students that they advise. Each department has a set of faculty members, and each faculty member, in turn, teaches one particular course. The Department objects in the database each contain the department's name, chair, set of faculty, and set of majors. Each Course object contains a course's id, name, textual description, instructor, and the set of students who are taking the course. Finally, each class whose attributes are detailed in Figure 1 also has an associated collection (its extent) in which all instances of the class and its subclasses are recorded.

3.2 Browsing Complex Objects To begin a PESTO query/browse session, the user selects a database to explore and chooses one or more collections from which to begin querying and browsing. The bottom left-hand corner of Figure 2 shows PESTO's startup window, titled \OO-SQL/QB." This window lists the available databases; in Figure 2 the user has chosen to explore the database called UnivDB, so the window also lists all the top-level collections in the UnivDB database. (Schema browsing is not an emphasis of our work, so PESTO is currently rather primitive in this regard.) In Figure 2 the user has chosen to use the Students collection as an entry point for browsing. PESTO is entirely schema-driven, so the student window (labeled \Students0") shown on the left side of PESTO's \Data Browser" window in Figure 2 is the default display window that PESTO produces for Student objects. Immediately underneath this student window's pulldown menu bar and row of buttons is a label 6

class Student (extent Students) { Int ss_no; String last_name; String first_name; Float gpa; Ref advisor; Set major; Set taking; }

class Department (extent Departments) { String name; Ref chair; Set faculty; Set majors; } class Course (extent Courses) { String id; String name; Ref description; Ref instructor; Set takers; }

class GradStudent: Student (extent GradStudents) { String office; String phone; } class Professor (extent Professors) { String last_name; String rank; String area; Int phd_year; Ref photo; Ref dept; Ref course; Set advisees; }

Figure 1: Example schema (UnivDB). bar indicating the source of the window. It contains the label \Students0" to indicate that it is a window for browsing the Students collection; \0" is needed because a user can decide to browse a collection independently through more than one window, in which case the additional student windows would be labeled \Students1," \Students2," and so on. This bar also tells which element of the collection is being examined and how large the collection is. Each attribute of the Student class is visible in the default student window1 , and this window currently displays a Student object that was returned by the underlying object database system. Attributes of primitive data types, e.g., ss no and last name, are shown as being contained in the Student object. Attributes that are references or collections of references are presented as buttons 1 Default display windows can be customized, via a pulldown option that enables users to hide or show attributes of the objects displayed in the window.

7

Figure 2: Synchronously browsing students. that will bring up other windows for displaying the object(s) targeted by the reference(s). The advisor attribute is an example of a reference attribute, and in Figure 2 the user has clicked on it to bring up a window for the referenced Professor object; the user then repeated this action on the advisor window's photo attribute to bring up the advisor's photograph as well. The user has clicked on the button for the taking attribute to bring up a course window (labeled \Students0.taking," as per the window labeling convention described below), which currently shows the rst of several courses that the displayed student is enrolled in, and on the course window's description button to bring up the associated Text object describing that course.2 Each window created by navigating via button clicks from the student window has a label bar that indicates how it depends on the other windows (e.g., \Students0.advisor" for the professor window, \Students0.advisor.photo" for the associated Image window); in addition, lines are drawn to visually connect dependent windows in the browse area. 2 PESTO provides defaults for various display aspects. Reference buttons are normally labeled with their referenced class name and an indication of whether the attribute is a reference or a set of references (Student.advisor versus Student.taking). Optionally, PESTO permits class de ners to provide special (possibly data-dependent) icons for the reference button for objects of the class (Professor.photo, Course.description). Similarly, PESTO allows custom displayers to be associated with particular classes. While the student, professor, and course windows are all default windows that PESTO generated using schema information, the image and text windows show custom displayers that were provided for these classes.

8

Near the top left of Figure 2's student window are PREVIOUS and NEXT arrow buttons for stepping through the objects in the Students collection. When a collection window is displaying the rst (last) object in the collection, the PREVIOUS (NEXT) arrow is disabled and grayed out; otherwise, both arrows are enabled and shown in solid black. Because a student can take several courses, the course window also has PREVIOUS and NEXT buttons. This window represents a nested collection of objects, and at present it contains the rst element of the taking set for the currently displayed student (Navin Kabra). The NEXT and PREVIOUS arrows of this window can be used to browse through the set of courses that this student is taking. The other windows shown have no NEXT/PREVIOUS arrows because they were derived from single-valued references, so each has just one associated object. When dependent windows are being displayed, browsing is synchronous (as in KIVIEW [Motr88] and OdeView [Agra90]) { when the user clicks on the NEXT (PREVIOUS) arrow in the student window, this window will advance to the next (previous) object in the Students collection. When this happens, the contents of the dependent windows change as well { the professor window displays that student's advisor, the course window displays the rst of that student's courses, and so on. The course window's NEXT and PREVIOUS arrows can then be used to browse through the set of courses that this next student is enrolled in. Continuing across the top row of buttons in the student window in Figure 2, the button to the right of the NEXT arrow is the EXPAND button for the window. This button gives the user the option of seeing the window's objects as a member of their most speci c applicable class { for example, clicking on the student window's EXPAND button will allow the user to view the extra information available for those students that are graduate students. To the right of the EXPAND button is the QUERY (?) button, which is discussed in the next subsection. Next to the QUERY button is the TABLE button, which will allow the user to see multiple objects of a single collection at a time. At the far right is the EXIT button, which closes the window (recursively closing its dependent sub-windows) and discards the associated browse state.

3.3 Query-In-Place in PESTO From the description thus far, PESTO may sound like a schema-driven rewrite of OdeView. However, PESTO goes beyond OdeView in supporting ltered browsing through the query-in-place paradigm. While browsing all students and their courses might be of interest to some UnivDB users, many would prefer to browse only a selected subset of the students, or perhaps only a selected subset of their courses. This can be done by utilizing PESTO's query-in-place features, which allow users to specify and then browse a desired subset of a given collection of objects. PESTO allows any collection-valued window { whether top-level or nested { to be the target of a query, and browsing the result objects of a query has the look and feel of browsing an unrestricted object collection (except that only objects satisfying the query speci cation are visible). As an example, assume that the user is browsing students together with their courses and associated instructors, but is only interested in students who have grade point averages higher than 3.5 who are taking one or more computer science graduate courses from instructors whose research 9

Figure 3: Browse students with high GPAs who are taking some CS graduate course taught by a database professor. area is databases. To restrict the set of students being browsed, the user can use the QUERY button in the student window to put it (and its dependent windows) in query mode; the boxes associated with each attribute value become predicate entry boxes. The user can then enter the the GPA predicate in the student window, the graduate-level CS course predicate in the course window, and the instructor's area predicate in the professor window, as shown in Figure 3. Clicking GO tells PESTO to execute the query and return to browse mode to view the results.3 The resulting browse state is similar to basic synchronous browsing. Now, however, the set of browsable Student objects is restricted to those that satisfy the user's criteria, and the magnifying glass icon in the student window will be highlighted to remind the user that the query is active there. The NEXT and PREVIOUS buttons in the student window enable the user to browse through all students that satisfy the query predicate; the NEXT and PREVIOUS buttons in the course window still enable the user to browse through any/all courses that the current student is taking, not just graduate CS courses taught by database professors, as the purpose of the predicate is only to restrict the set of Students being browsed. In the example above, the user wished to see only those elements in a top-level collection (e.g., Students) that satisfy some criteria. Because PESTO is intended for object databases, where objects can contain nested collections of (e.g., sets of references to) other objects, PESTO permits queries to be speci ed in any window associated with a collection { whether it is a top-level collection or a dependent collection. In contrast to the previous example, suppose that the user wishes to browse all students, but to see only their CS courses taught by database professors. Starting from the same browse state as the previous example, Figure 4 shows how this can be done. This time, the user The box that says "Execute Query" appears in the gure because PESTO's \balloon help" feature is enabled. Since the user's cursor is pointing at the GO button, PESTO is displaying a small window that explains the purpose of this button. 3

10

clicks on the QUERY button of the course window to place the course window and its subordinate professor window in query mode; the student window will remain in browse mode this time. The user enters the desired predicates on courses and their instructors, as shown in the gure, and then hits GO to launch the course query. In the resulting browse state, the student window can be used to browse through all of the students, as in un ltered browsing. However, the dependent course window now provides browse access, for each student, just to courses that are CS courses taught by database professors. (For browsed students taking no such courses, the course and instructor windows are grayed out.) The lter icon in the course window is highlighted as a reminder that this window is showing only a ltered subset of its associated objects (like the magnifying glass for a top-level collection). The user is now browsing a top-level collection (Students) in an un ltered manner, but ltering the contents of a nested collection (Students.taking).

Figure 4: Browse all students plus their CS graduate courses taught by database professors, if any. In general, PESTO allows simultaneous queries ( lters) at as many levels as a user wishes. This generality is one of PESTO's most useful (and unique) features, as it allows users iteratively to browse through a complex database and narrow their browsing scope as they go. Filter predicates can be added to any window associated with a collection, at any level of nesting, at any time during a browse session. Thus, users can begin by synchronously browsing a collection, decide that they don't want to see everything, add a lter, decide that they don't really want to see all of the objects in a given subwindow, add a lter to limit the objects being browsed there, and so on. In addition to this general query-in-place support for objects at multiple levels of nesting, PESTO provides a short cut for an important special case. Consider again the query shown in Figure 3, where the user asked to browse students with high GPAs who are enrolled in a graduate CS course taught by a database professor. PESTO's response to this query allowed the user to synchronously browse these students and all of the courses that they are taking (together with the instructors of those courses). This is what the user wanted in our earlier example. However, a dierent user might wish to use the students' course criteria (graduate CS courses taught by 11

database instructors) to lter the courses as well { thereby viewing only those courses that caused each student to be selected for browsing. To support the case where a user wants to place an existential predicate on a nested collection, and to place the identical query predicate on the nested collection itself, PESTO provides a FILTER button. This button appears in nested collection windows whenever a query on an ancestor window causes them to enter query mode. To use it, the user would proceed as in Figure 3 { but before saying GO, the user would click the FILTER button (which then becomes highlighted) in the course window to ask PESTO to lter the Course objects as well. The browse state resulting from this short cut is equivalent to the browse state that would result if the user rst speci ed the desired query for the student window and then repeated its course and instructor criteria as a separate query rooted in the dependent course window.

3.4 Iterative Query Re nement In addition to integrating querying and browsing via its query-in-place support, PESTO provides support for iterative query re nement throughout a query/browse session. This is an important feature of PESTO, both for naive users and for users who wish to do serious query-based exploration of non-trivial object databases. In this area of its functionality, PESTO provides support for returning to and then editing the previous query. Also supported is a query history mechanism that enables older queries to be located, re ned, and resubmitted. Together, these features ensure that PESTO users can incrementally focus their attention on the objects of interest and that they can back up and try again if they discover that they have taken a \wrong turn" while doing so.

3.4.1 Re ning the Last Query Whenever a user enters query mode, the latest query is recalled to the screen, ready for incremental editing. For example, if the user's query in Figure 3 turned out to be too selective, e.g., due to an overly high choice of GPA, the user could hit QUERY and modify that portion of the query predicate; hitting GO then launches the newly modi ed query. Also, PESTO allows aborting a query without losing the browse state. If a user gets part way through specifying a new query, and then decides not to proceed with the new query after all, hitting the REVERT button (the \turn around" arrow visible when a window is in query mode) returns to the exact browse state { with all of the same objects in all of the same windows { that existed before entering query mode. These query re nement features also serve another purpose { recovery from disorientation during a complex query/browse session. After entering a query, although a magnifying glass or lter icon indicates that a query is active, no details of the query predicate are displayed as the results are being browsed. If for some reason users forget exactly what their ltering criteria were, they can re-enter query mode by pushing the QUERY button in the student window { causing PESTO to re-display the current query. Then, having had their memory refreshed, they can revert back to browsing.

12

3.4.2 Query History Support Being able to edit the most recent query addresses the most common case, but it doesn't handle cases where a user makes an exploratory mistake (or a series of such mistakes) and wishes to back out through several queries { returning to an earlier, perhaps more successful query. To handle such cases, PESTO includes a query history feature when windows are in query mode (e.g., see the student window in Figure 3). PESTO remembers the last max-queries (a settable con guration parameter) queries for each window; these are the max-queries most recent queries that were targeted at this window. The arrow-based buttons that look like PAGE-UP and PAGE-DOWN icons in the query window can be used to walk back and forth through this history to select a previous query to edit. Once the desired query has been found and edited, it becomes the new most-recently-issued query, and it is added to the most recent end of the query history.

4 PESTO Semantics and Complex Queries The previous section gave an overview of the basic look and feel of PESTO, illustrating how its graphical, query-in-place approach supports synchronous browsing of objects { both without, and with, query-based ltering of the browsed object sets. In this section, we will discuss the semantics and complex query capabilities of PESTO, describing the conceptual model upon which its design and implementation are based and then covering its expressive power and its various advanced query features.

4.1 Object-Oriented User Interaction It should be evident from the previous section that the interaction model that PESTO presents to its users is heavily object-oriented { in the sense that there is a direct correspondence between each window in PESTO's browse area and an object in the underlying database.4 PESTO's query-inplace approach is intended to allow users to directly examine and manipulate the displayed objects. As a result, in browse mode, each window keeps track of the OID of its displayed object; windows thus represent \live" objects. We will not be discussing updates or method invocation in detail here, but the PESTO design allows users to update an object displayed in a browse window by choosing an update action and then directly editing its contents. Similarly, users can invoke an object's methods from a pulldown list provided in the display window's menu options. Each update or method invocation causes PESTO to ask the underlying database system to apply the requested operation to the object associated with the window. PESTO's behavior (and semantics) in query mode is based on a similarly tight correspondence between windows and objects in the database. Roughly speaking, each window in query mode represents an object variable in a query formed through the user's actions. Queries are always rooted One exception will be discussed later { ad hoc join queries lead to \synchronizer" windows that do not directly correspond to stored objects. 4

13

in a particular window, the one that the user has placed in query mode, and their meaning is \let me browse the objects that satisfy the predicate speci ed here and in any/all dependent windows." Each top-level collection window represents an object quanti er that ranges over its associated collection in the resulting query. Each dependent collection window in the scope of the query represents a quanti er that ranges over the appropriate collection in its parent window's current object; dependent reference windows can be thought of similarly (i.e., as one-element collections), though most object query languages support a path expression syntax that makes it possible to deal with reference windows without needing explicit quanti ers for them. To make this clear, let's look at a concrete example of a query. The following is the OOSQL [Kier95] that PESTO will generate and associate with the student window when the user hits GO in Figure 3; notice that the student and course windows each have corresponding quanti ers (S and T, respectively), while the professor window's contribution to the generated query is captured by a path expression rooted at a reference attribute of the course window's quanti er (T.instructor).5 As its result, the query asks for the OIDs together with the full data content6 of the Student objects that satisfy the query predicate: select distinct S, S.*

from Students S

where S.gpa > 3.5 and exists ( select T from (S.taking) T where ( T.id >= 'CS 700' and T.id < 'CS 900' and T.instructor is not null and T.instructor..area = 'Databases' ));

As an aside, this discussion highlights a key dierence between PESTO's query capabilities and those of QBE and its commercial descendants. The QBE paradigm makes a strong distinction between queries and results { tabular forms are used to specify queries; in general, a separate result table is needed to browse the query results. In contrast, with PESTO's query-in-place paradigm, the query criteria are entered, in place, into browse windows that have simply been placed in query mode. PESTO displays the results in the same windows, thus retaining their complex object structure and enabling their component objects to be \live." As mentioned earlier, PESTO allows users to be simultaneously browsing at some levels of a complex object structure while querying at others. This is another feature that distinguishes PESTO from QBE-like interfaces. For this feature, PESTO relies on the query language of the underlying OODB system to support queries over collections that are nested within a speci c object. Given this support, which can be found both in OO-SQL and in ODMG's embedding of 5 The query fragment `and T.instructor is not null' is automatically included by PESTO because of the fact that path expressions, by default, involve outer-join-like semantics [Zani83]. In this case, however, its inclusion is redundant, because it is implied by the presence of a path predicate that must also be satis ed; this will be clearer in Section 4.2.2. 6 If some attributes were hidden, then the generated query would explicitly request only the non-hidden attributes instead of using S.* to request all of them.

14

OQL in C++ [Catt94], it is relatively straightforward for PESTO to support multi-level querying and synchronous browsing of the results. PESTO simply maintains an association between each query and the window at which it is rooted, generating the query using the model discussed above for top-level queries. The only dierence for queries whose root windows are non-top-level is that they will be rooted at a nested collection and will be re-evaluated each time the object being displayed in its immediate parent window changes (to maintain proper window synchronization).

4.2 Expressing Complex Queries Earlier, we made the claim that PESTO makes it \easy" for users to express complex queries. We now examine this claim in detail by explaining how PESTO supports a large class of object queries: select/project queries, complex structural queries (including existentially and universally quanti ed nested structures), a limited form of disjunctive queries, queries involving ad hoc valuebased and/or identity-based linking (i.e., ad hoc joins), and queries involving complex, type-speci c predicates. We then discuss certain kinds of queries that PESTO cannot express (and why).

4.2.1 Select/Project Queries The most basic form of query in PESTO is roughly equivalent to a relational select/project query. PESTO's support for ltered browsing of a top-level collection, combined with its support for hiding some of the attributes of the objects to be displayed in a given browse window, provides this level of expressive power. As illustrated earlier, users specify their selection criteria by entering values or expressions into the attribute entry boxes of the collection's display window after putting it in query mode. Users can enter values (or SQL-style like patterns for strings) to specify equality predicates, and PESTO supports a simple predicate language that has the usual comparators and logical connectives (and, or, and not) to allow complex predicates to be expressed for individual attributes. (E.g., see the course id predicate in Figure 3.) Between attribute boxes in a given window, PESTO's semantics are conjunctive, as one would expect. Finally, PESTO supports complex negative selection predicates by providing a NOT button in each query window; when pressed, this button negates the entire predicate implied by that window and any dependent windows. As an example, if a user wants to see all professors except those who are full professors (i.e., whose rank is Professor) who specialize in theory and who received their Ph.D. degree either since 1990 or before 1970, they can express this desire to PESTO as shown in Figure 5.

4.2.2 Complex Queries on Objects References in an object database can be null-valued; for example, a department may not have a chairperson (at the moment). PESTO must provide users with a way to say whether they want the parent object to qualify when the query involves predicates on the dependent object and the reference is null. By default, dependent objects are said to be mandatory, meaning that a parent object is considered to satisfy the full query predicate only if a dependent object exists and satis es its portion of the query predicate. As a concrete example, consider the query in Figure 6, where the 15

Figure 5: Do not show full professors who specialize in theory and who received their Ph.D. recently or long ago. user wishes to browse departments where the chairperson is an associate professor. Departments with a null chair attribute will not be browsable in the result, as they do not qualify by default. To allow the user to see such departments as well { to browse departments whose chairperson, if they have one, is an associate professor { PESTO includes a button labeled OPTIONAL in the dependent professor window of Figure 6. Pressing this button, which appears in each dependent window of a query window, makes the existence of a dependent object optional there instead of mandatory. This same idea applies to dependent collection windows. When browsing departments and their faculty members, placing an associate professor rank predicate in the Faculty window means that the user wishes to see departments that have at least one associate professor. If they press the OPTIONAL button, they will see departments where, if they have any faculty members at all, at least one is an associate professor. Collection-valued reference attributes raise another question { does the user want to require the predicate to be true for some members of the collection, or for all of its members? The former case corresponds to existential quanti cation, and the latter to universal quanti cation. To support both cases, PESTO provides an additional button, labeled ALL, whenever a dependent window corresponds to a collection-valued attribute. By default, a predicate in such a window has existential (or \some") semantics; pushing the ALL button means \this predicate must hold for all objects in this nested collection," thereby providing universal quanti cation over the nested collection's elements. For example, the query in Figure 7 means that the user wants to browse computer science courses in which all of the enrolled students have high GPAs and have an advisor, if any, who is a full professor. PESTO's provision of the OPTIONAL and ALL options in dependent windows makes it possible for users to express many queries that would otherwise be complicated to express in an object query language. Compare Figure 7 to what the user would need to say in OO-SQL to achieve the same 16

Figure 6: Browse departments whose chairperson is an associate professor.

Figure 7: Browse CS courses in which all enrolled students have high GPAs and an advisor (if any) who is a full professor.

17

semantics: select distinct C, C.* from Courses C where C.id like 'CS %' and not exists ( select T from (C.takers) T where not ( T.gpa > 3.5 and (T.advisor is null or T.advisor..rank = 'Professor') ));

Finally, it is worth noting that the ALL and NOT buttons in a dependent window can be combined as a way to say \none." This combined semantics arises because NOT helps to form the window's local predicate, while ALL modi es the type of quanti er associated with the window. For example, by pressing both the ALL and NOT buttons in Figure 7, the user could have instead asked to browse computer science courses in which none of the enrolled students have both high GPAs and an advisor, if any, who is a full professor. (Equivalently, this speci es computer science courses in which all of the enrolled students do not have both high GPAs and an advisor, if any, who is a full professor).

4.2.3 Disjunctive Queries As mentioned earlier, PESTO supports a small predicate language for specifying the conditions on attributes. Disjunctive predicates can be speci ed using this facility, as illustrated by the phd year predicate in the professor window in Figure 5. This predicate language addresses an important, but rather restrictive, class of disjunctions. To support a wider range of disjunctive queries, PESTO provides \power users" with the notion of an OR-stack that can be associated with a collection window when it is the target (i.e., root window) of a query. As an example, suppose that a user wishes to browse students with high GPAs who are taking CS courses taught by a database professor or with low GPAs who are taking English courses from a professor named \Smith." To express this request, the user enters the rst part of this disjunctive query just as in Figure 3. However, instead of pushing GO at this point, the user will instead push the OR button in the student window, activating the student window's OR-stack. In response, PESTO records the rst part of the predicate and then clears the student window and its dependent windows so that another disjunct may be entered. The user can now ll in the rest of the conditions. The OR button is highlighted to indicate the presence of multiple disjuncts on the OR-stack, and the upward and downward arrows to the right of the OR button can be used to move up and down through the OR-stack, allowing each disjunct involved in the query to be viewed and modi ed while the window is in query mode.

18

4.2.4 Ad Hoc Joins (Links and Synchronizers) As described in [Bati91], many graphical query tools that support object-like queries, such as graphical E-R-based tools, only permit joins along paths in the database that are supported by existing relationships. In contrast, the PESTO graphical query language supports value-based linking as well { and in a way that ts naturally with the rest of PESTO's object query facilities. We introduce the concept of a synchronizer, which is a transient object resulting from a query that binds together two or more otherwise unrelated database objects. To users, PESTO synchronizers look like database objects that happen to contain only reference attributes; they provide a handle for conveniently and synchronously browsing the results of an ad hoc join query in a way that is consistent with the treatment of other browsed collections. Such a concept is not necessary (and therefore not found) in relational query tools, as users of those tools browse result tables containing attribute data that has been copied out of the query's source tables. In contrast, PESTO's synchronizers enable the user to retain links to the underlying (live) objects in the database. As a result, all of PESTO's query-in-place and query re nement features work when a user is querying and/or browsing via synchronizers as well. Suppose that a user wishes to browse student/professor pairs where the student and the professor have the same last name. They begin by opening independent top-level windows on the Students and Professors collections and placing either one in query mode. To specify the join criterion, they link the last name attributes by clicking on last name, rst for the window in query mode, and then for the other window. PESTO detects this link request, highlighting the source and target attribute names as they are selected. Once the target is selected, and found to be an independent window, PESTO creates a synchronizer window, placing both previously independent windows under its control, in query mode. PESTO also puts up a menu bar at the top of the browse area that shows the linking (comparison) operators that make sense for the data type of the selected link attribute. Figure 8 shows the screen at this stage of the join process. The user then selects the \=" comparator. At this point, PESTO is ready for the user to enter any additional query predicates and then press GO to execute the query. Additional predicates could be other links or path predicates rooted at either (or both) of the collections being joined. Note that the join query as a whole is rooted in the synchronizer window, which is where the GO button is located. Once the user hits GO, the synchronizer can be used to sequence through the results. Figure 9 shows how this looks in our example; when the NEXT (PREVIOUS) button in the synchronizer is pressed, PESTO will show the user the next (previous) student/professor pair whose last names match. When the user is done browsing the join results, pushing the EXIT button in the synchronizer window will free the student and professor windows (making them each independent top-level browse windows again) and remove the synchronizer from the screen. PESTO's links support a variety of interesting queries. In addition to joins of independent collections, links can be used to join across existing dependent and top-level windows. Moreover, links can be made between simple attributes, pairs of reference attributes, a reference attribute and a nested collection of references, or a simple attribute value and a nested collection of values. By 19

Figure 8: Almost ready to run the Student/Professor join. combining links with the features for negation and universal quanti cation, many complex queries can be expressed, such as \browse the students who are taking no courses taught by their advisor."

4.2.5 Type-Speci c Predicates Last but not least, PESTO also allows for specialized data types, like Text or Image data, that require type-speci c query predicates when formulating queries (e.g., approximate image matching, or keyword searches for text). PESTO was heavily in uenced here by the approach that the Garlic project's object SQL dialect takes to handling such predicates [Care95]; namely, they are expressed as method calls. PESTO supports an extensible set of type-speci c methods called pickers for such data types. The class de ner for a specialized data type is permitted to add a picker function that PESTO can call. This function interacts with the user, presumably by putting up a window, and is expected to return a string containing a method call or a boolean expression made up of method calls. PESTO then grafts this string onto its internal data structure that represents the query being built up. (See Section 5 for more internal details and [Cody95] for more about this approach.)

20

Figure 9: Synchronously browsing the Student/Professor join results.

4.2.6 Limitations PESTO is fairly powerful in terms of the types of object queries that users can ask. Of course, while it supports quite a range of queries, it is not a relationally complete query facility (nor is it intended to be). It can express many of the queries that OO-SQL [Kier95] supports, including queries that involve selection, projection, path expressions, nested sets, existential and universal quanti cation, value-based joins, and type-speci c predicates. In addition, we are prototyping extensions to support sorted results for collection windows, aggregates, and certain kinds of method calls in queries. All of this work is driven by PESTO's user interaction model { namely, that windows on the screen, in almost all cases, should represent live objects drawn from collections in the underlying database. This model is important for PESTO's intended usage, which is to support interactive exploration and manipulation of the contents of object databases. In addition, there is an important tradeo to be made between the expressiveness of PESTO as a query language and its usability and consistency as a tool for non-expert users; we do not wish to sacri ce the latter in favor of the former. So what are the limitations and/or oddities of PESTO as a query language? Due to PESTO's object-oriented interaction model, relational projection is not actually supported, though it can be 21

simulated via attribute hiding. Also, relational joins { which create new objects out of attribute data copied from pairs of other objects { are not supported, though matching and pairing is supported via links and synchronizers. The relational union operation is also not supported. PESTO's ORStack allows users to specify a limited class of union queries, where the unioned subqueries all range over the same underlying collection. However, PESTO is not powerful enough to express unions that combine objects from multiple collections, though this could potentially be addressed using a synchronizer-like notion. In any case, we do not intend for PESTO to ever support the unioning of objects of dierent types that are union-compatible only in the relational sense; that would be wholly incompatible with our object-oriented user interaction model. Finally, while we plan to add some degree of support to PESTO for sorting, aggregates, and grouping, the power of these facilities will again be limited to what can be done within the con nes of our object-oriented model. (E.g., aggregates and grouping may be limited to aggregate-by-parent-object queries, so that users can easily express aggregate requests like \browse the average GPA of students grouped by major department" but not \browse the average GPA of students grouped by last name.")

5 Implementation Details To enable fast prototyping of our ideas, PESTO has been implemented at the University of Wisconsin using the Tcl language and the Tk toolkit from UC Berkeley [Oust94]. In addition, we have used public domain Tcl/Tk extensions where possible to simplify the initial development process. PESTO currently runs on the IBM Garlic system prototype [Care95], which supports an objectextended dialect of SQL. Garlic runs under AIX, and it currently provides object-based access to data which is managed by DB2/6000, ObjectStore, and the QBIC [Nibl93] image manager. PESTO also runs on the OO-SQL query interface to ObjectStore [Kier95]. The remainder of this section brie y discusses two aspects of PESTO's current implementation, its portability and its support for content-based queries on specialized data types.

5.1 Portability To make PESTO portable, we de ned a small set of Tcl procedures for the PESTO front-end to use when interacting with the underlying object database system. This interface sits beneath PESTO and is called PASTA.7 The PASTA interface allows PESTO to connect to an object database, nd out what collections it has as entry points, get their type information, set up a portal (i.e., an iterator) for sequencing through the objects in a collection, submit a query and set up a portal for its answer set, sequence through the objects referred to by a portal, retrieve an object's content based on its OID, apply a method to an object, and so on. Tcl is a string-oriented language, so all data types (integer, boolean, short, long, oat, double, and OIDs for object references) ow in ASCII form between PASTA and the underlying object database system. Types and data values in the 7 PASTA stands for Portability Abstraction for STructured Archives; it is obviously important to have PESTO over PASTA...

22

underlying system must be described to PASTA in terms that it understands; however, PASTA's type repertoire was heavily in uenced by ODMG-93 [Catt94], which has a rich enough type system to approximate most other object data models that we have encountered in the literature and in practice. In addition to the Tcl PASTA interface, PESTO provides a corresponding set of C++ function calls (which sit just beneath the Tcl PASTA interface) to enable non-Tcl-speaking implementors who wish to port PESTO to a new object database system to do so by implementing the PASTA connection to their system in C++ instead of in Tcl.

5.2 Specialized Data Types As mentioned above, PESTO permits the implementors of specialized classes, such as text, image, and other multimedia data types, to provide customized displayers and/or predicate formation tools for their classes. We refer to such customized predicate formation tools as pickers. Currently, the implementor of a displayer or picker is expected to know Tcl (and Tk), and customization of PESTO is handled by editing one of its internal tables to indicate the presence of a customized picker or displayer. We brie y cover the mechanism for adding a picker here. To enable PESTO to use a customized picker for a specialized data type, the picker implementor is required to provide four new Tcl routines for the data type of interest. This has been done in Garlic for the image query tools associated with the IBM QBIC system [Nibl93]. When the user clicks on the reference button for a data type that has its own picker when in query mode, PESTO invokes a \pick" command to cause a type-speci c picker window to appear. The user can then interact with the picker. When the user hits GO in the top-level query window, PESTO issues a \get" command to ask the picker for a string that PESTO can and into the rest of its internal representation for the query; this string typically calls for the application of some sort of \match" method (with picker-speci ed arguments) to the target object. The \get" command also causes the picker to unmap itself from the display. To support PESTO's query history facility, pickers are required to provide a \repick" function that will reestablish their query speci cation from a previously returned query string. Finally, the PESTO picker protocol includes an \exit" function that PESTO uses when it wants to completely shut down a picker at the end of a session. (Otherwise, for performance reasons, PESTO \caches" idle pickers during a query/browse session for possible reuse later in the session.)

6 Conclusions We have described the design and implementation of PESTO, an integrated query/browser interface that supports exploratory access to object databases. Like other object browsers, PESTO allows end users to navigate an object database by following the relationships that exist among its objects. In addition, PESTO supports a unique query-in-place paradigm that allows users to query as well as browse the database in a natural and integrated fashion, without actually writing object queries. We believe that PESTO's query facilities strike a good balance, being intuitive yet powerful; support 23

is provided for path predicates, structural and value-based joins, universal quanti cation, negation, and a variety of complex conjunctive and disjunctive predicate forms. In addition to these object query features, PESTO allows class de ners to add customized display and predicate formation tools to handle specialized data types such as images or text. Finally, the internal architecture of PESTO was designed so that it can be ported to run on any object database system that supports query-based access to its objects. The features described here are all included in the current PESTO prototype, and so far PESTO has been ported to two object database interfaces (Garlic and IBM's OO-SQL interface to ObjectStore). Our near-term PESTO plans include completing support for a number of additional features. These include additional support for end-user display customization (modeled after similar features in commercial relational query tools), updates, and method invocation. We are also prototyping a tabular collection window for displaying and scrolling through multiple objects of a collection at a time; synchronous browsing is retained by having one of the displayed objects highlighted as the current object. We plan to experiment with, and possibly oer, other display paradigms for nested collections (e.g., nested collection windows that are physically nested inside their parent window, or the \dive-in" navigational paradigm used in popular web browsers like Netscape). Important medium-term plans include a usability study, to compare PESTO's ease of use against that of textual object-oriented query languages, and formal work to precisely characterize the expressive power provided by PESTO's graphical query paradigm. Another medium-term plan includes a rewrite of PESTO in Java in hopes of achieving both a more structured internal implementation and web enablement as a side eect. Finally, in the longer term, we plan to expand PESTO's level of display customization support, e.g., to enable object-oriented views to be de ned graphically.

7 Acknowledgements Rakesh Agrawal was a key participant, in the early days of the Garlic project, in the design discussions that gave birth to PESTO. We thank John Thomas, who implemented the PASTA protocol on top of Garlic, and Mary Tork Roth, the nder of many bugs in early versions of PESTO. Bill Cody's input and assistance were invaluable in making the PESTO/QBIC connection happen, and Denis Lee helped to re ne the PESTO picker protocol by turning the existing QBIC interface into PESTO's rst provider of type-speci c predicates. We are grateful to Jerry Kiernan for providing us with access, at the University of Wisconsin, to the OO-SQL prototype. Finally, we thank Roger King and Eben Haber for providing us with some of their favorite pointers into the database user interface literature.

References

[Ande86] L. Anderson, E. Ecklund, and D. Maier, \Proteus: Objectifying the DBMS User Interface," Proc. Int'l. Workshop on Object-Oriented Databse Sys., Sept. 1986. [Agra90] R. Agrawal, N. Gehani, and J. Srinivasan, \OdeView: The Graphical Interface to Ode," Proc. ACM SIGMOD Conf., May 1990.

24

[Bati91] C. Batini et al, Visual Query Systems, Tech. Rep. 04.91, March 1991. [Bryc86] D. Bryce and R. Hull, \SNAP: A Graphics-based Schema Manager," Proc. IEEE Data Eng. Conf., 1986. [Borr92] P. Borras et al, \Building User Interfaces for Database Applications: The O2 Experience," SIGMOD Record 21(1), March 1992. [Care95] M. Carey et al, \Towards Heterogeneous Multimedia Information Systems: The Garlic Approach," Proc. 1995 IEEE RIDE Workshop, March 1995. [Cody95] W. Cody et al, \Querying Multimedia Data from Multiple Repositories by Content: The Garlic Project," Proc.IFIP 2.6 Working Conference on Visual Database Systems - 3, March 1995. [Catt88] T. Rogers and R. Cattell, \Entity-Relationship Database User Interfaces," in Readings in Database Systems (1st Edition), M. Stonebraker (ed.), Morgan Kaufman, 1988. [Catt94] R. Cattell (ed.), The Object Database Standard: ODMG-93 (Release 1.1), Morgan Kaufman, 1994. [Cruz92] I. Cruz, \DOODLE: A Visual Language for Object-Oriented Databases," Proc. ACM SIGMOD Conf., June 1992. [Davi86] J. Davison and S. Zdonik, \A Visual Interface for a Database with Version Management," ACM Trans. on Oce Info. Sys., 4(3), July 1986. [Fogg84] D. Fogg, \Lessons from a "Living In a Database" Graphical Query Interface," Proc. ACM SIGMOD Conf., June 1984. [Flyn92] B. Flynn and D. Maier, \Supporting Display Generation for Complex Database Objects," SIGMOD Record 21(1), March 1992. [Gold85] K. Goldman et al, \ISIS: Interface for a Semantic Information System," Proc. ACM SIGMOD Conf., May 1985. [Gyss90] M. Gyssens, J. Paredaens, and D. Van Gucht, \A Graph-Oriented Object Database Model for Database End-User Interfaces," Proc. ACM SIGMOD Conf., May 1990. [Habe94] E. Haber, Y. Ioannidis, and M. Livny, \Foundations of Visual Metaphors for Schema Display," J. Intelligent Info. Sys., 3(3/4), July 1994. [Habe95] E. Haber, Y. Ioannidis, and M. Livny, \OPOSSUM: Desk-Top Schema Management through Customizable Visualization," Proc. 21st VLDB Conf., Sept. 1995. [Kier95] J. Kiernan and M. Carey, \Extending SQL-92 for OODB Access: Design and Implementation Experience," Proc. of the ACM Int'l. Conf. on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA), Oct. 1995. [King84] R. King and S. Melville, \SKI: A Semantic-Knowlegeable Interface," Proc. 10th VLDB Conf., Aug. 1984. [Kunt89] M. Kuntz and R. Melchert, \Pasta-3's Graphical Query Language: Direct Manipulation, Cooperative Queries, Full Expressive Power," Proc. 15th VLDB Conf., Aug. 1989. [King87] R. King and M. Novak, \Freeform: A User-Adaptable Form Management System," Proc. 13th VLDB Conf., Aug. 1987. [King89] R. King and M. Novak, \FaceKit: A Database Interface Design Toolkit," Proc. 15th VLDB Conf., Aug. 1989. [King92] R. King and M. Novak, \Building Reusable Data Representations with FaceKit," SIGMOD Record 21(1), March 1992. [Motr88] A. Motro, A. D'Atri, and L. Tarantino, \The Design of KIVIEW: An Object-Oriented Browser," Proc. 2nd Int'l. Conf. on Expert Database Sys., April 1988. [Nibl93] W. Niblack et al., \The QBIC Project: Querying Images by Content Using Color, Texture and Shape," Proc. SPIE, Feb. 1993. [Oust94] J. Ousterhout, Tcl and the Tk Toolkit, Addison-Wesley, 1994. [Rowe82] L. Rowe and K. Shoens, \FADS { A Forms Application Development System," Proc. ACM SIGMOD Conf., June 1982.

25

[Rowe85] L. Rowe, \Fill-in-the-Form Programming," Proc. 11th VLDB Conf., Aug. 1985. [Silb91] A. Silberschatz, M. Stonebraker, and J. Ullman, \Database Systems: Achievements and Opportunities," Comm. ACM 34(10), Oct. 1991. [Spoe93] A. Spoerri, \InfoCrystal: A Visual Tool for Information Retrieval," 1993, Tech. Rep. No. MITCECI-TR 93-2, MIT, 1993. [Ston82] M. Stonebraker and J. Kalash, \TIMBER { A Sophisticated Relational Browser," Proc. 8th VLDB Conf., Sept. 1982. [Ston89] M. Stonebraker and E. Neuhold, The Laguna Beach Report, ICSI Tech. Rep. No. 1, Berkeley, CA, June 1989. [Ston93] M. Stonebraker et al, \DBMS Research at a Crossroads: The Vienna Update," Proc. 19th VLDB Conf., Aug. 1993. [Wong82] H. Wong and I. Kou, \GUIDE: Graphical User Interface for Database Exploration," Proc. 8th VLDB Conf., Sept. 1982. [Yao84] S.B. Yao et al, \FORMANAGER: An Oce Forms Management System," ACM Trans. on Oce Info. Sys., 2(3), July 1984. [Zani83] C. Zaniolo, \The Database Language GEM," Proc. ACM SIGMOD Conf., May 1983. [Zloo77] M. Zloof, \Query By Example," IBM Sys. J. 16, Dec. 1977.

26