A Visual Interface for Synchronous Collaboration and ... - CiteSeerX

A Visual Interface for Synchronous Collaboration and Negotiated Transactions Lutz Wegner, Manfred Paul, Jens Thamm, Sven Thelemann Universität Kassel, FB Mathematik/Informatik, D-34109 Kassel, Germany1 email: {wegner, mpaul, injt, thele}@db.informatik.uni-kassel.de

Abstract: This paper introduces a visual interface for computer-supported cooperative work (CSCW). The interface is an extension of the editor interface of ESCHER, a prototype database system based on the extended non-first-normal-form data model. In ESCHER, the nested table approach is the paradigm for presenting data, where presenting includes browsing, editing and querying the database. Interaction is achieved by fingers generalising the well-known cursor concept. When several users are involved, the concept permits synchronous collaboration with the nested table acting as “whiteboard“. We discuss its use in applications which require negotiated transactions, i.e. where the isolation principle of ACID-transactions gives way to negotiations. We also give examples of how interactive query formulation in a QBE-like fashion can support the collaboration. The arguments in the paper are mainly supported with screenshots taken from two applications, one of them also with non-textual data types which are seamlessly integrated into the nested tabular display paradigm.

1 Introduction ESCHER is a prototype database system supporting non-standard applications in engineering, science, trade, and tourism. ESCHER originated in 1987 as part of a joint research project with IBM Scientific Centre Heidelberg and became operational in 1989 as a database editor [Weg89, Weg91, KTW90]. The underlying data model is an extension of the classical NF2 (non first normal form) data model [AB84, Dad+86, SS86, Lars88]. The user interface of ESCHER features tabular representations of hierarchical (nested, or NF2-) views of database instances, including non-standard data types like pixel data. It provides the fundamental means of interaction for browsing and editing of complex objects [PTW94], visual query formulation and query result display, as well as interactive schema design. At present, ESCHER’s primary role is that of a platform for experimental research. Current topics are advanced storage techniques [WPTT95], object-oriented modelling, type extensions, and language aspects [Pau94, The95], user interface issues like visual query formulation and extensions for multimedia applications, and finally computer supported cooperative work (CSCW) as presented in this paper. In a joint project with industry, part of the representation and editing techniques for complex objects are being ported to a 4GL. They will become part of one of the next releases of a large business processing system. The current research version of ESCHER is available as public domain software for IBM RS/6000 and HP 9000 series under OSF/Motif. The remainder of this paper is organized as follows. In Section 2 we describe ESCHER’s tabular representations of schemas and tables. The discussion includes our approach to interaction by means of so-called fingers, which are a generalisation of the well-known cursor concept. 1. Work supported in part by SAP AG, Walldorf, Germany

1

Section 3 will then focus on the main topic of this paper, namely extensions towards synchronous collaboration [DR93], also known as computer-supported cooperative work [IEEE94], with the nested table acting as a “whiteboard“. We discuss CSCW in the context of a particular application which requires negotiated transactions, i.e. where the isolation principle in ACIDtransactions [GR93] gives way to negotiations. Section 4 continues the application example and shows how ESCHER’s QBE-like query formulation can be integrated into the framework. In Section 5 we present a different application example which also includes non-textual data and Section 6 summarizes the paper.

2 A Tabular Approach to Nested Structures ESCHER’s primary way of displaying database instances is in nested tabular form with the structure of the table, also called the table schema, displayed above the table. As an example, consider Figure 1, which shows a set of employees. Each tuple contains a list of courses as well as a set of projects which are associated with this employee. Access to the data is provided by means of so called fingers [Weg91]. They generalise the cursor paradigm in graphical and text editors. On the graphical display, a finger is reflected by a colored area which corresponds to the object a finger is currently pointing at. In a table more than one finger may point to objects, one of which is the active finger and is used for navigating through the table.

Figure 1: A snapshot of the EMP table In Figure 1 finger F1 is the active one. The colored areas indicate that F1 is positioned on a NAME-tuple. Note that there are actually two colored areas: apart from the data object, the

2

corresponding structure in the schema part is also shaded. The mode is Browse because atomic values cannot be entered for complex attributes. When the user descends to the atomic fields of this complex attribute, the mode-indicator will change to Edit-mode and the data entry widget at the lower left will become activated. Note also the way null values are shown: the entries ?s?, , and {???} are null values of string, list, and set type. Essential operations on fingers are the navigational operations “going into an object“ (In, i.e. descending into the next deeper nesting level), “out to the surrounding object“ (Out), “to the next object“ (Next, staying on the same nesting level), and “to the previous object“ (Prev, Back). These operations are also used internally, e.g. when the trees representing a query are matched against schema and table tree. At the graphical interface, the user navigates through the instances using the same basic finger operations, but may also use the mouse to move the active finger to the area of interest. Mouse clicks get translated in a sequence of finger operations. Atomic attributes are updated by going once more “into“ an atomic object and modifying the current value. A finger is also used to design the schema of a table. Figure 2 shows a snapshot from the session which created an EMPLOYEES-schema to go with an EMPLOYEES-table containing the instances. Figure 2 is largely self-explaining. Finger F1 points at a null structure (indicated by ???), a substructure yet to be defined. The common delete-/insert-operations can be used to modify this schema which is then finally stored under its own name in the application database.

Figure 2: A snapshot from schema definition To better understand the role of fingers and their way of navigating through tables and schemas, it is helpful to have a conceptual idea of how NF2-objects are stored as trees. Figure 3 shows the table tree with finger F1 pointing to the NAME tuple of the fourth employee. The figure also illustrates that a finger is a path from the root of the tree to the node to which the fin-

3

ger points. It is therefore only natural to represent fingers by stacks of node addresses. As schemas are also stored as NF2-objects, there is another stack of node adresses for F1 into the schema tree. We omit showing the schema tree here. finger stack 1 EMPLOYEES

2

{}

… …

…

ENO

NAME

3 = Top

[]

[]

4 []

…

[]

…

[]

COURSES



{}

PROJ

4714

LAST

FIRST

“Newcome“

[]

[]

[]

“Rita“

CID

CID

DATE “C++“

7-95

“Tcl/Tk“

PID

DATE 11-95

“Escher“

BUDGET 20000

Figure 3: Object tree with stack for a table finger

To conclude this short overview, we like to mention that ESCHER implemented multiple fingers from the very beginning with the fingers mainly acting as “bookmarks“ in large tables. However, the concurrency aspect which arises when fingers are owned by different users (more precisely to individual transactions) was never exploited. This will be the topic of the next section.

3 Synchronous Collaboration and Negotiated Transactions 3.1 Extended Transaction Models and Human Decision Making One of the great advantages of a DBMS is the transaction principle. It is based on the four ACID properties: atomicity, consistency, isolation, and durability [GR93]. Already in the early eighties, transaction processing was well understood and serializability became the main correctness criterion, although semantic knowledge can lead to stronger criteria. Concerning transactions in general, Korth [Kor95] mentions that the principle has in fact been known in the world of trade and commerce for several thousand years1. Thus it is not surprising that transactions re-emerge in all kinds of applications, e.g. as long lived transactions in design applications like CAD/CAM. Solutions for these types of applications can be found under the generic name extended transactional models and include e.g. the ConTract, ACTA,

1. Even today, a handshake marks the “commit“ of a sale, lease or similar transaction in many rural areas of Germany as it has been the custom for several centuries

4

NT/PV, and ASSET models [Elm92, BDG+94] for nested, split, compensating and chained transactions, as well as sagas. Recently, focus on workflow management created further “evolution of the transaction model [which] is a shift from machine-oriented concepts to human-oriented concepts,“ as Korth emphasized. He continues to point out that the key ingredient is interaction and that the human performance determines the throughput of the system, i.e. “the quantity to be maximized is human information transfers per second (HITS)“ as opposed to transactions per second (TPS) [Kor95]. Korth also suggests, that in the transition to the human transaction processor, the ACID properties might change to something like the following [Kor95]: • Atomic → Structured, but flexible • Consistent → Mostly consistent, with exceptions clearly noted • Isolated → Cooperative, Negotiated • Durable → Auditable trail of responsibility Clearly, the main difference is giving up isolation in favour of cooperative action (negotiation). This must be supported by advanced visual interfaces to database systems. To strengthen our argument that ESCHER’s finger paradigm together with nested tables serve well for negotiated transactions, we present scenes from a freight shipping application (Figure 4). 3.2 Application Outline The table shows a subset of freight items classified by origin, destination, delivery time, weight and size. The outermost nesting is origin (freight centers) which are listed in North-South order for trucks travelling the Berlin-Kassel-Salzburg or Hamburg-Kassel-Basel stretches. The grouping on the next level below is by destination (only those further South or East/West), i.e. cities where trucks may stop to unload and reload, if necessary. New freight items are inserted by (human) agents at any time with the shipper id set to null. Freight companies regularly scan the table to pick up suitable items to arrange into runs. An item is aquired by a shipper if his name (shipper code) is inserted in the shipper field. Primary goal of shippers is to maximize the load along a run, e.g. along the Hamburg-Salzburg line. However, feasible schedules are subject to numerous constraints, e.g. weight restrictions for each substretch, maximal driving times of drivers, congestions on roads on certain days and times, penalties for late delivery, co-operations with other companies, shared trucks, etc. In general, the job of day-to-day ad hoc scheduling is too complicated to be fully automated. Most importantly, the market is highly competitive and there is considerable bargaining and need for negotiations, as sub-optimal schedules are highly dangerous for the minimal profit margins in the road transportation business. Thus shippers will often exchange or give away certain already scheduled loads if it saves them a stop or detour. In Figure 4 the reader can see a shipper (owning and navigating a finger highlighted by a certain color) looking for items to fill a 1 ton gap on the Hamburg-Basel run. He could either opt for the 750 kg available directly in Hamburg or try to combine Hamburg-Kassel with Kassel-Basel, Hamburg-Frankfurt with

5

Figure 4: Concurrent visual freight brokerage Frankfurt-Basel, or (sub-optimally) Hamburg-Kassel with Frankfurt-Basel. Figure 4 also shows some other competitors with fingers belonging to their transactions. 3.3 Negotiation and Cooperation Rules Knowing certain market pecularities, shippers will aquire some loads as a starter and then wait, observing the trading, to supplement the run later. The application is thus typical for long duration transactions. On the other hand, because of its similarity to open multi-player games, there must be rules to be enforced by the cooperative transaction system. One of them is a time limit from start-of-transaction to either commit or abort. Typically, a shipper should have less than 20 minutes to complete a run if trading is heavy. This avoids overcrowding the table with partially assigned loads1 and too many fingers. Another set of rules is needed to avoid “hogging“ orders. One policy is “you touch - you buy“, i.e. once the shipper enters his code, the item is firmly reserved for him. Another policy is to 1. Items remain visible until the transaction is completed and are then collectively removed. If a shipper wants to trade afterwards, a compensating transaction must be started.

6

have a fee for each reservation but with an option to return the item. Limiting the number of concurrent fingers per transaction and the number of concurrent transactions per shipper is another way of speeding up the process. Clearly, visual clues play an important role. As an example, a user (shipper) might see activities of his competitors but their identity is not revealed (all but his own fingers appear in the same color without further information). In this scenario, a shipper must explicitly ask for the identity of a competitor if exchange of orders is wanted. A supervisor may then be called who can reveal the identity because he has mappings of fingers to transactions and transactions to owners. Another major factor is queuing up for an order in the case where other transactions have a lock on the item but might free it again. If this policy is offered, a user may navigate onto an item on which the fingers of other users already rest. Figure 4 shows in the left corner a small table which gives additional information for this option. For each finger belonging to the transaction which is associated with the window, WAIT- and HOLD-values indicate how many other fingers of other transactions are queued in front and how long the user must wait for all in front of him to release the object, provided none of them removes the object. The times can be calculated from the remaining transaction times. Based on this information, the user can then decide whether it is worth to wait or to move on. Having several fingers assigned to one transaction (forked off from the active finger) is essential in this situation. In ESCHER, jumping between several fingers acting as bookmarks is very easy (pressing a key-combination corresponding to a finger causes the visible portion of the table to be redrawn with the new active finger centered). Thus, a shipper can check his other “markers“ while waiting for a particular item. ESCHER also permits opening as many (overlapping) windows on the same table as wanted (with the size of screen usually being the limiting factor), so users can concurrently observe several areas of interest. Another beneficial factor is the data model with nested tables. A finger can move great distances with few key strokes on the outer level, yet can also handle detailed data after entering into a complex object. Nesting also helps when several fingers are on the same object: an item is reserved when the shipper id is entered in the SHIPPERID-field. An item is also effectively “locked“ when a finger moves onto an item which has no other finger on it. Clearly, moving the finger onto an item is a prerequisit for entering the shipper id. Other fingers (from other transactions) may follow and may (on purpose or accidently) point to the same item, e.g. in the hope that the first finger moves on without making a reservation, as mentioned above. A reserved item is removed if and only if the transaction commits, i.e. the commit collects all items that have been reserved by a shipper during one transaction. Naturally, fingers still “sitting“ on these items must be moved. In the case of flat tables, the other cursors would have to be placed on the “line“ above or below which can be confusing. In the case of ESCHER, the finger “escapes“ (moves) to the surrounding complex object, here the set of loads. This clearly indicates that the preferred item is gone and that the user must choose from the remaining set or move on to another city. Note that having several fingers on one object, with the first arriving having the right to modify/delete the object, constitutes one form of “dirty read“ which is normally forbidden in

7

classic transaction systems. However, in the visual case, it might be permissible since the reading transaction is aware of the fact that the first transaction has the right to update, resp. delete the object. Efficient physical and logical locking techniques, which also must take into account the complex object data model [HDKRS89], are currently under investigation. 3.4 Architectural Considerations We conclude this application example by looking at the bandwidth requirements of this cooperative work. Figure 5 shows the general setup with clients viewing one or more nested tables and initiating finger operations by creating mouse and keyboard events at the clients. client 1 finger F1i

object tree

. . .

finger events

server data pages

data items Finger F1i

client n

finger events data items

finger Fnj

Finger Fnj

object tree Figure 5: Networking for synchronous collaboration

At first it seems that keeping the n displays synchronous would require a very high effort on the side of the server and/or high bandwidth for communication. Fortunately, that is not the case because we do not transmit screen images and only transport those data items which are relevant to a local window1. Clients rather send finger operations to the server, e.g. a keyboard “enter“ event forces a finger Fk to do an in-movement which translates into a “push Fk“-message2. Similarly, a mouse click on a scroll bar of Window Ws, which moves the visible portion of a table independently of finger movements, triggers a data request from the server. On the server side, a pool of fingers is maintained together with a mapping from fingers to clients.

1. Interestingly enough, the fairly large table from Figure 4 still fits into one 4 KB-page. Of course things change when pixel data come into play as in the case of the 2 MB table of Figure 7. 2. Messages are actually commands of a script language which is modelled after Tcl [Ous94] and drives the Object Manager interface of ESCHER.

8

This concept has some similarity with Machura’s [Mach94] publisher-subscriber system for the graphical user interface of a cooperative design database. There, a server has the task of monitoring changes and to notify clients of changes at other clients. However, this system is mainly based on link traversal and separate lists are maintained for graphical and textual objects while ESCHER ships portions of its object tree to clients but maintains a central database at the server.

4 Query Support in Synchronous Collaboration Human decision making involves assessing situations and collecting information. Nested tables permit fast scans on the outer levels as long as the user has knowledge of how the data are arranged (sort order, order related to geographical location, entry order, etc.). In large tables, queries must supplement browsing. ESCHER’s tabular approach suggests a QBE-like style for queries.

Figure 6: Searching for a one ton item to go to Basel The idea of using a template to fill in values which must be matched by a query goes back to Zloof’s landmark paper [Zlo77] introducing the QBE (Query-By-Example) language for the

9

relational data model. Templates corresponding to relations of the database schema are filled in to express selection predicates. Variables (the “examples“) express relational joins. Projection symbols specify the schema of the result table. Additional references concerning examplebased query languages may be found in [ÖW93]. ESCHER follows the template paradigm but with some interesting modifications due to the complex object data model (see [WTWL95] for details). Here we only give an example to show how ESCHER’s query facility interacts with the interface for synchronous collaboration. In Figure 6 we are searching for a one ton item which has “Basel“ as destination. The condition is thus a conjunction. The query is formulated by filling out a template which is provided by the query manager upon definition start. The user must then specify the subschema where a search finger should stop in the searched table(s) (which corresponds to the .P-entries in QBE or the SELECT-part in SQL). In our example we could stop on a tuple from the TO-set where CITY is “Basel“ and the LOAD-set contains a suitable item. The more practical solution is to directly stop the result finger on the item which could then be reserved. In case more than one item satisfies the predicate, a next button appears and allows moving from a hit to the next one. The example also shows that queries in synchronous collaboration environments must be able to accomodate temporal aspects: we might only be interested in those tuples which have no one else waiting, or where the waiting time is less than, say, 5 minutes. ESCHER’s self-referential way of keeping metadata in ordinary NF2-tables might be helpful in this context but more research is needed.

5 Extensions to Other Data Types Making travel arrangements is frequently cited [BDG+94] as a typical example of a long duration transaction. In fact, human booking agents quite often spend ten or more minutes per customer doing compensating transactions (release previously booked seats) because flight reservations systems will hold a lock on a seat for only two minutes, thus many seats are booked “just to be on the safe side“. With the increased trend towards networking, e.g. electronic shopping, on-line banking, booking of trains, flights, and hotels, the need for computer-supported cooperation will become more pressing. At the same time, the demands for pleasing interfaces increases which implies offering various non-textual datatypes, like pixel pictures, vector graphics, sound, and video. In this section we show how ESCHER can accomodate these non-textual data types. Presently, ESCHER features import, export, storage, and display of GIF (up to 256 colours), JPG (truecolour) and XBM (bitmap) pixel pictures. As an example, Figure 7 shows a nested table for a hotel information system with the cursor positioned on a hotel in Hamburg. The placement of the cursor might result from running a query formulated in a QBE-like fashion with “Hamburg“ entered in the city-field as explained in Section 4. Extensions for on-line booking with actual availability data provided in a network are omitted. In ESCHER a pixel-valued attribute can participate in the usual editor operations, like cut-andpaste. Also the usual finger operations could operate inside a pixel picture, i.e. to clip part of the picture and to zoom (stepwise IN/OUT finger operation). It could also be moved to a QBE-

10

Figure 7: Screenshot for hotel application template to serve as search criteria except that search conditions involving pictures have not been defined. Particular application algorithms for feature extraction, as considered in [JC88, GWJ91], are outside the scope of this paper. On the other hand, bitmap data can easily be used to enhance the expressiveness of query results and play an important role in synchronous collaboration. The obvious case is to make the picture(s) integral part of the selected tuples, as with x-ray pictures in medical information systems, floorprints and pictures of houses for sale in the real estate business, or hotel pictures in a tourist information system. Depending on the weight of the picture, the remaining textual information can be considered as an annotation of the picture, which can guide the search, or conversely, the picture is simply an add-on. Continuing along this line of design, a pixel picture can be used to transform textual information, e.g. a hotel location when a street plan is added to the city tuple in the hotel example above. Moving the finger to a particular hotel creates a corresponding marker in the street plan which can be the base for “negotiations“ in cooperative work: “is this hotel close enough to

11

your conference site which I marked with a blue circle or would you rather consider the location marked with the red finger ...?“. Again, this falls well within ESCHER’s tabular visualization paradigm. Apart from pixel data, geometrical data can be easily handled within ESCHER and, in fact, had been operational until the system was moved to a different platform [WPC92, Ram92]. In this design, geometric data (points, lines, polygons, circles, ...) coexist with a graphical representation of these data. Navigating through the object tree results in edge and point marking of objects as known from the common drawing tools. Collaboration on graphical data with several fingers concurrently manipulating graphical objects in the display translates directly into fingers manipulating an ESCHER table. Also, QBE-like queries can now be started on the numeric representation of the graphical data, e.g. to place the finger in sequence on all objects which have at least one point whose x-value is above a certain constant, or are shaded in a particular color, or form a subgroup with less than ten components, etc. Finally, synchronous collaboration and QBE-like queries as part of network browsing, e.g. in the Web, is of interest. As a preliminary step, we have implemented ESCHER’s display style for NF2 tables using HTML. Schema and table instance have to be entered in a straightforward linear textual format. Query results transmitted this way will then lead to tabular displays on any system which supports HTML. As for query formulation, however, HTML provides insufficient interaction expressiveness to support ESCHER’s finger paradigm. Figure 8 shows a sample screenshot from one of our Web pages. Any reader interested in further details of this networking aspect is invited to visit our WWW-server at http://gretel.db.informatik.uni-kassel.de/

Figure 8: NF2 table produced with HTML for use on the Web

12

6 Related Work and Conclusion The last five years have seen an explosion of visual user interfaces developments [ACM92]. There are already too many to list or even mention in detail: the FADIVA home page linked to the cfp of this conference mentions 21 information visualization systems alone, a survey of visual query systems in 1991 [BCCL91] mentions more than 25. Among the many visualization and interaction paradigms, two stick out as being very fundamental: representing information as a graph where object A is related to object B iff there is a path from A to B and, secondly, as a table where relationship is expressed by means of juxtaposition of rectangles. There is some consensus that the former method is more suited to the task of conceptual design [Chen76] or for questions of boolean nature, e.g. in answering a question like “can I travel from A to B with at most one change of train and at which places would I have to change“. When details matter, e.g. when the question involves departure and arrival times, type of train, days of operation, etc., tables are hard to beat. Queries can be formulated on graphs (consider e.g. the QBD* and Hypergraph approaches [ACS90, CT94]) as well as on tables or forms. The fact that QBE has found so many extensions (see [ÖW93] for a survey) suggests that tables might be more practical for real world applications. The same argument holds for integration of non-textual data, e.g. images, which ESCHER supports much in the way Office-by-Example [W+87] does. Aggregate functions and extensions toward spreadsheets also speak in favor of the tabular approach. On the browser side, both visualization paradigms are possible: tabular interfaces similar to ESCHER which are suitable for the casual user are the form-based approaches [Kita84, KK89, YHSL84]. Browsers which navigate along the arcs of a graph representing entities and relationships or class hierarchies are described in [ADD+92, Kun92, BH90]. Systems which provide both a tabular as well as a graph-based display style are forthcoming, but presently mostly for schema management [HIL95]. When looking at the needs of CSCW-systems, it is clear that browsing, editing, and queries must be integral part of the interface with visual clues on concurrent action built on top. If so much speaks for a tabular approach, it is only natural to continue along this line with negotiated transactions and synchronous collaboration. ESCHER’s nested tables are one prerequisit for efficient solutions because they organize the data in a tree-shaped form which suits decision making well (cf. Figure 4: first decide where to load up the truck, then decide where to go, finally pick out the suitable items). Concurrent fingers are the other ingredient to replace isolation in transactions by negotiations and awareness of multi-user access. In summary, we see ESCHER much like a flight guidance system for navigating over “data space“. Its QBE-like query facility acts as a type of autopilot. By entering appropriate coordinates, ESCHER will direct the user without additional effort to the target area from where he or she can navigate to make “a visual landing“ on a specific data tuple. At the same time, the window acts as a “radar screen“ making the user aware of other collaborators or competitors and

13

possibly warning him or her of obstacles and giving hints on avoiding collisions and how to minimize delays.

References [AB84]

S. Abiteboul, N. Bidoit. Non First Normal Form Relations: An Algebra Allowing Data Restructuring. - Rapp. de Recherche No. 347, INRIA, Rocquencourt, France, Nov. 1984

[ACM92]

ACM SIGMOD Record, Vol. 21, No. 1, March 1992 (Special issue on Advanced User Interfaces for Database Systems)

[ACS90]

M. Angelaccio, T. Catarci, G. Santucci. QBD*: A graphical query language with recursion, IEEE TSE 16:10 (Oct. 1990) 1150-1163

[ADD+92]

A. Auddino, Y. Dennebouy, Y. Dupont, E. Fontana, S. Spaccapietra and Z. Tari. SUPER: A Comprehensive Approach to Database Visual Interfaces, Proc. IFIP Work. Conf. on Visual Database Systems (E.Knuth and L.M.Wegner (eds), Budapest, Hungary, 30.9-3.10.1991, Elsevier Science Publishers (North-Holland) 1992, pp. 365-380.

[BCCL91]

C. Batini, T. Catarci, M.F. Costabile, S. Levialdi. Visual Query Systems. - TR No. 04.91 (March 1991), Dipartimento di Informatica e Sistemistica, Universita degli Studi di Roma “La Sapienza“

[BDG+94]

A. Biliris, S. Dar, N. Gehani, H.V. Jagadish, K. Ramamrithan. ASSET: A System for Supporting Extended Transactions, Proc. SIGMOD 94, Minneapolis, Minn. (May 1994) 44-54

[BH90]

Daniel Bryce, Richard Hull: SNAP: A Graphics-based Schema-Manager. - In: Stanley B. Zdonik, David Maier (eds.): Readings in Object-Oriented DatabaseSystems. - San Mateo, CA, Morgan Kaufmann (1990) 537-550

[Che76]

P.P. Chen: The Entity-Relationship model - towards a unified view of data. - ACM TODS, Vol. 1, No. 1 (1976), pp. 9-36

[CT94]

T. Catarci, L. Tarantino. Databse Qeurying by Hypergraph Manipulation, in Proc. 2nd Int. Workshop on Interfaces to Database Systems (Pete Sawyer Ed.) Lancaster University, 13-15 July 1994, Springer Verlag, London, 84-103

[Dad+86]

P. Dadam, K. Küspert, F. Andersen, H. Blanken, R. Erbe, J. Günauer, V. Lum, P. Pistor, G. Walch. A DBMS Prototype to support extended NF2 relations: An integrated view on flat tables and hierarchies. Proc. ACM SIGMOD Conf. on Management of Data, Washington, 1986, pp.356-366

[DR93]

P. Dewan and J. Riedl. Toward Computer-Supported Concurrent Software Engineering, IEEE Computer 26:1 (Jan. 1993) 17-27

[Elm92]

A. K. Elmagarmid (ed). Database Transaction Models for Advanced Applications. Morgan Kaufmann, 1992

[GR93]

J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. Morgan Kaufmann, 1993

[GWJ91]

A. Gupta, T. Weymouth, and R. Jain. Semantic Queries in Image Databases. Proc. IFIP Work. Conf. on Visual Database Systems (E.Knuth and L.Wegner eds.), Budapest, Hungary (1991) ElsevierScience Publ. (1992) 201-215

[HDKRS89] U. Herrmann, P. Dadam, K.M. Küspert, E.A. Roman, and G. Schlageter. A Lock Technique for Disjoint and Non-Disjoint Complex Objects, IBM Heidelberg SC, Germany, TR 89.01.003 (Jan. 1989) [HIL95]

Eben M. Haber, Yannis E. Ioannides, Miron Livny. OPPOSSUM: Desk-Top Schema Management through Customizable Visualization, Proc. 21. VLDB, Zürich, Switzerland (1995) 527-538.

[IEEE94]

Special issue on Computer-Supported Cooperative Work, IEEE Computer, 27:5 (May 1994)

[JC88]

T. Joseph and A. Cardenas. PICQUERY: A High Level Query Language for Pictorial Database Management, IEEE TSE 14:5 (May 1988) 630-638

[KK89]

H. Kitagawa and T.L. Kunii. The Unnormalized Relational Data Model For Office Form Processor Design, Springer, Berlin-Heidelberg-New York (1989)

[Kita84]

Kitagawa, et al. Form Document Management System SPECDOQ. - Proc. ACM SIGOA Conference on Office Information Systems, Toronto, Ont., Canada, June 25-27, 1984 (published as

14

SIGOA Newsletter, Vol. 5, Nos. 1-2), 1984, pp. 132-142 [Kor95]

H.F. Korth. The Double Life of the Transaction Abstraction: Fundamental Principle and Evolving System Concept, Proc. 21st VLDB, Zürich, Switzerland (1995) 2-6

[KTW90]

K. Küspert, J. Teuhola, and L. Wegner. Design issues and first experience with a visual database editor for the extended NF2 Data Model. Proc. 23rd Hawaii Int. Conf. System Science, Jan. 1990, pp. 308-317

[Kun92]

M. Kuntz. A Versatile Browser-Editor for NF2 Relations. - Proc. 2nd Far-East Workshop on Future Database Systems, Kyoto, Japan (Apr. 26-28 1992), pp. 266-275

[Lars88]

P.-A. Larsen. The data model and query language of LauRel. - IEEE Database Eng., Vol. 11, No. 3, 1988

[Mach94]

M. Machura. A Graphical User Interface for a Cooperative Design Database, in Proc. 2nd Int. Workshop on Interfaces to Database Systems (Pete Sawyer Ed.) Lancaster University, 13-15 July 1994, Springer Verlag, London, 289-305

[Ous94]

J.K. Ousterhout. Tcl and the Tk Toolkit. Addison-Wesley, Reading, Mass., 1994

[ÖW93]

G. Özsoyoglu and H. Wang. Example-Based Graphical Database Query Languages, IEEE Computer 26:5 (May 1993) 25-38

[Pau94]

M. Paul. Typerweiterung im eNF2-Datenmodell. Ph.D. thesis, University Gesamthochschule Kassel, Department of Mathematics/Computer Science, 1994

[PTW94]

M. Paul, S. Thelemann, L. Wegner. User Interface Techniques based on the Non-First-NormalForm Data Model. Technical Report 14/94, Department of Mathematics/Computer Science, University Gesamthochschule Kassel, Dec. 1994

[Ram92]

A. Ramsay. A Graphics Interface for ESCHER, Project Report, Dept. of CS, The Univ. of Queensland, June 1992

[SS86]

H.-J. Schek, M. Scholl. The Relational Model with Relation-Valued Attributes. - Inf. Systems, Vol. 11, No. 2, 1986, pp. 137-147

[The95]

Sven Thelemann. Assertion of Consistency Within a Complex Object Database Using a Relationship Construct, Proc. 14th Int. Conf. Object-Oriented & Entity-Relationship Modelling, Bond Univ., Qld, Australia, Dec. 13-15, 1995

[W+87]

K.-Y. Whang et al. Office-by-Example: An Integrated Office System and Database Manager, ACM TOIS 5:4 (Oct. 1987) 393-427.

[Weg89]

L.M. Wegner. ESCHER - Interactive, Visual Handling of Complex Objects in the Extended NF2 Data Model. Proc. IFIP Work. Conf. on Visual Database Systems, Tokyo (April 1989) 277-297

[Weg91]

L.M. Wegner. Let the Fingers Do the Walking: Object Manipulation in an NF2 Database Editor. Proc. “New Results and New Trends in Comp. Science“ (H. Maurer, ed.), Graz/Austria, June 1991, Springer LNCS 555 (1991), pp. 337-358

[WPC92]

L. Wegner, M. Paul, R. Colomb. Variants and Recursive Types in the eNF2 Data Model, The Univ. of Queensland, Key Centre for Software Technology, TR 233, June 1992

[WPTT95]

L. Wegner, M. Paul, J. Thamm, and S. Thelemann. Pointer Swizzling in Non-Mapped Object Stores, Preprints Fachbereich Mathematik/Informatik, Univ. Kassel, TR 4/95 (August 1995), to appear in Proc. ADC’96, Melbourne, 29.1.-2.2.96

[WTWL95] L.Wegner, S.Thelemann, S.Wilke, and R.Lievaart. QBE-like Queries and Multimedia Extensions in a Nested Relational DBMS, Sept. 1995, submitted for publication. [YHSL84]

S. Bing Yao, A.R. Hevner, Z. Shi, and D. Luo. FORMANAGER: An Office Forms Management System. - ACM TOIS, Vol. 2, No. 3, July 1984, pp. 235-262

[Zlo77]

M. Zloof. Query-by-Example: A data base language, IBM Systems Journal 6 (1977) 324-343

15