Object Manipulation in an NF Database Editor 1. Introduction

reprinted from: Proc. "New Results and New Trends in Computer Science" (H. Maurer ed.), Graz/Austria, June 20-21, 1991, Springer LNCS 555 (1991) 337-358

Let the Fingers Do the Walking: Object Manipulation in an NF2 Database Editor Lutz M. Wegner Universität Gh Kassel, FB 17 Mathematik-Informatik Postfach 10 13 80, D-3500 Kassel Abstract. The Non First Normal Form (NF2) data model tries to combine a natural, hierarchical view of structured values with the expressivness and clarity of relational operations. While it is a very powerful data model, it is not easy to handle and even harder to implement. Here we describe an interactive approach to object manipulation in a database editor called ESCHER. The interface is engineered around the pointing paradigm using so-called fingers (cursors). The paper proceeds from the visualization of fingers to their internal representation as stacks of addresses, lists the permissible operations on fingers and shows how they support internal tasks. 
























1. Introduction ESCHER is a visual editor for complex objects in the extended Non First Normal Form (eNF2) data model. This data model not only includes nested relations (sets) - see e.g. [AB84, HP89, Lars88, SS86] for the "pure" NF2 model - but also lists, multisets, and tuples in arbitrary combinations and to any depth of nesting [Dad86, KTW90, PT86, Weg89]. Values of these types are called complex objects and form trees of (sub-)objects. At the leaves are the atomic objects with the usual types integer, real, text, Boolean, etc. ESCHER also provides types for references to objects (links), vector graphics, bit-map pictures, and methods in the form of interpretable scripts or compiled and linked programs.



ESCHER displays tables and schemes in in a tabular way in windows and permits browsing and editing of the displayed objects. Navigation through objects and manipulation of objects is by means of so-called finger operations, where a finger is a two-dimensional cursor which points to an object. On the screen, any object which has a finger pointing to it is displayed with the particular background color assigned to the finger. 







In many ways ESCHER therefore corresponds to a three-dimensional spread-sheet. Since it does not claim to be fully object-oriented, it is less ambitious than most of the "next generation" prototypes built lately: Bubba [Bor90], Exodus [CDRS86], AIM-P [Dad86], O2 [Deux91], DAMOKLES [DGL87], Iris [Fish87], Zeitgeist [Ford88], Starburst [Haas90], PRIMA [Härd87], ORION [KGBW90], DASDBS [SPSW90]. On the positive side, ESCHER shows remarkable performance in "real-time" editing even on modest workstations, has a highly sophisticated memory management and is available in source code as an open system for extension and experimentation by any interested party. Historically, it is an offspring of AIM-P, developed at the IBM Heidelberg Scientific Center, and was originally conceived as a test tool for duplicate elimination for the NF2 data model [KSW89] 1). 













1)

ESCHER is a joint project with the IBM Heidelberg Scientific Center. Financial support from IBM Germany is gratefully acknowledged.

1



Context Manager

Windows, Keyboard Interaction

Visual Manager 

Navigational Interface

Sets, Lists, Tuples Cursors (Fingers) 

Object Manager

Trees, Nodes, Buckets Element Identifiers

Data Manager



Record Manager

Stack of Windows Lists of Fingers Table-Schema Pairs

Files, Handles, Pages Record Identifiers

Fig. 1: ESCHER’s layered architecture



ESCHER is built upon the principle of self-referential structures, i.e. it employs the very same algorithms and data structures which are offered to the user for its own management. Thus, a schema which contains names, types, degree (arity) and display information of an object is itself an object with a schema of its own, namely the so-called BootScheme, which is the schema of all schemes, including itself. Another example is the set of all named objects, called the Pool, which includes the BootScheme, the PoolScheme and itself, i.e. the Pool. 





This paper is the last in a series of three papers describing the layered physical storage architecture of ESCHER. It deals with the top-most layer which forms a navigational interface to the yet higher layers, like Visual and Context Manager (see Figure 1). The paper proceeds in two stages: first the so-called fingers are introduced as a human interaction paradigm, their visualization is shown in several examples and the set of permissible operations for the user is discussed. Then, in a second, more technical stage, the translation into internal structures is given. Although this paper is self-contained, it might be useful at times to refer to earlier descriptions of the interface [KTW90] and to internals of the lower layers given in [Weg90, Weg91]. 



















2. The Finger Paradigm Spoken and written language is the most refined way of communicating a person’s intentions to other human beings or to machines. Where it is not possible, gestures are often used as an inferior, but handy alternative. Typically, gestures (e.g. pointing to an item or pressing a button from a list of buttons) are needed in situations where a different, not understood language is spoken, where there are missing or disturbed transmission channels, or when the opponent has no fully developed interpretation capacity like e.g. today’s computers.

2

In the case of database systems, SQL has become the standard language for relational DBMS. From the very beginning, however, it was clear that simpler interfaces might suffice for restricted problem domains, like browsing in tables and small editing tasks. Thus, several interactive interfaces for databases where developped [BH86, Fogg84, Kita84a, Kita84b, LY81, Shu85, SK82, YHSL84, Zloof77] and there exists are large body of literature on their suitability (see e.g. [Rohr88] for an evaluation). 



In the case of nested relations, extending SQL to handle complex objects is possible, but - as the Heidelberg Database Language HDBL for the eNF2 prototype AIM-P [PT86] shows becomes quite complicated. As a consequence, a visual editor is even more needed than for flat tables. ESCHER, named after the famous Dutch artist M.C. Escher (1898-1972) [Ernst86], tries to fill this gap. 



!

As mentioned in Chapter 1, ESCHER displays tables and schemes in a tabular way using a separate window for each. Tables and schemes form top-level complex NF2 objects with subobjects nested inside. To manipulate these objects (change values, insert, delete, copy, move, ...), the user must "point" to the object(s). On the screen, the object pointed to is highlighted by "painting" it in a special color. This is the basic gesture paradigm from above and corresponds to the cursor in text processing or in graphical editors. In ESCHER, this two-dimensional cursor which points to the object is called a finger. 



ESCHER now extends the classical point-and-click paradigm in several unusual ways: •

Fingers come in pairs, e.g. one finger points to the object inside the table and the other points to the schema object (attribute name, etc.) which describes the table object. Several (pairs of) fingers can co-exist inside a table and exactly one of them is the active finger. Fingers seem to move in three dimensions (up/down, left/right, in/out) but actually there are only two dimensions: predecessor/successor, in/out). Movement of fingers is restricted by the structure of an object (compares to restricted movement of cursors in syntax-directed programming language editors). 

• • •

In Figure 2, a table with four books is shown. There are three fingers assigned to the table, one on the second book (F1), one on the second author of the second book (F2), and one on the set of keywords of the first book (F3). 

"

Examples of permissible finger movements are: 

• • •

#

• •

going with F1 to the next (third) book (pressing direction key "down" or "right") going with F3 to the YEAR attribute (pressing "up" or "left") going with F3 inside to the first keyword (algorithms), i.e. entering the set of keywords (pressing ENTER) going with F3 inside to the last keyword (pressing first ENTER and then END) going with F3 out to the first book (from the set of keywords to the book tuple) by pressing ESC.

Non-permissible movements are: • 

trying to go with F2 to the book’s TITLE; it is not "on the same level", the user must

3

,

{BOOKS} ,

.



{KEYWORDS} *

LASTNAME

TITLE -

#YEAR

INITIALS

KW algorithms searching sorting analysis of algorithms (

Knuth

*

D.E.

The Art of Computer Programming, Vol. 3

1973

)

)

(

&

&

Aho

A.V. 0

compiler construction

+

/

Sethi

R. *

Compilers: Principles, Techniques, and Tools

1

1986

formal languages

'

Ullman .

J.D.

The XYZ Manual

1989 3

2

Bucher Maurer

automata (

UNIX operating systems 1

W. Theoretische Grundlagen der Programmiersprachen

H.

1989

formal languages automata syntax semantics (

)

)

F1

F2

F3

Fig. 2: A table of books and its schema

• 

first escape to the list of authors and then may go to the successor attribute trying to go with F3 directly to the keywords of the second book.

As a particular case, an initial finger points to the table as a whole when it is selected from the Pool (by pressing enter on the corresponding entry). Conversely, escaping (press ESC) with the finger on the outermost object closes the window and returns the user to the Pool. Furthermore, the list of available fingers is shown at the bottom of the table window with the active finger blinking. Each finger is assigned a color. To stay compatible with EGA-graphics, six background colors are available for display fingers and two colors are reserved for "no finger on object" and "two or more fingers on the same object" (default is color black). 



%



$

The real power of the complex object data model in combination with the cursor paradigm becomes apparent when we carry over keystrokes from text processors. As more and more people become familiar with these products, it is essential that a database editor follows the analogy as closely as possible. Thus, pressing BACKSPACE when F2 is on the second author and is active deletes the first author. Pressing INSERT in the same situation creates a NULL-tuple object and opens input windows for prompting LASTNAME and INITIALS. 













#

Pressing BACKSPACE with F1 being active would delete the first book, but here a warning would be issued because another finger (here F2) rests inside. Similarly, pressing DELETE with F3 active deletes the complete set of KEYWORDS. Having a finger on the table of books as a whole and pressing DELETE removes the complete library and moves the user back to the Pool. Naturally, strict safeguards have to be included to prevent the user from loosing her/his complete database with a single keystroke.

4

Fingers are activated, resp. new fingers are created by pressing the corresponding function key (F1 to F6). Fingers are deleted by pressing ALT+Fi and similar arrangements exists when working with a mouse. The active finger also determines the location of the window into the table and follows the active finger as it navigates through the object. Table, schema, their filenames, handles, list of fingers, and windows (location on table and location on screen) together form a context. 4



5

6

Going from one table to another, e.g. via a "database pointer" (link), usually opens a new context visible as a new window either stacked on top of the previous, replacing the previous or tiling the screen with the previous. One example for this is the previously mentioned opening of an object from inside the set of available DB-objects, i.e. from the Pool. Most of these features have been described before (see e.g. [KTW90]) and belong to higher layers of ESCHER. Here we mention them to clearify the pointing paradigm and to illustrate which kind of operations will be needed on lower levels.



!

At present, we are working on adapting the interface to SAA’s Common User Access [IBM89], but quite a few interesting problems remain. In particular, large fields in small windows require intelligent solutions. One solution is stacking windows on top of each other, another is scrolling windows inside fields of the table. Collapsing a field to an icon is feasible and maintains the cursor paradigm. In general, we feel that too much emphasis is put on "features" these days and that there should be a move back to sound interaction semantics which, we hope, comes naturally with the NF2 data model.

3. Translating Fingers into Stacks From the preceding chapter it should be clear that fingers represent paths from the root of the object tree to an internal node or to a leaf. Entering (going into) a complex object extends this path, escaping from an object reduces the path. Internally fingers are therefore implemented as stacks. Going inside then becomes a push-operation and going to the surrounding object becomes a pop-operation. 

%

!





In this chapter we briefly sketch the internal storage representation which in turn permits us to discuss the implementation of fingers as stacks of volatile addresses. The details of the memory management, handled by the Data Manager, are presented in [Weg91]. ESCHER implements the classical two-level storage [JTTW91, SPSW90]. It consists of a

Fig. 3: Object tree, page buffer, and persistent storage

5

G

Root of tree; RID stored in table[2] of config. block of RM-file I

5

K

J

I

7

0

1

2 =

3 :

F

J

H

3

F

6 17 33

(32)

set D

7

;

9

0

1

4 B

2


4

7 11 1973 12

7

; :

(36)

ptuple 9

D

The Art of ... 0 7

1

7

8

; :

1

(24)

?

0

1


4

Compilers: ... (36)

sorting

algorithms

(28)

D.E.

Fig. 4: Object tree for LIBRARY as stored in core

6

to set of keywords

+

:

ptuple Knuth

4

D

set

2

>

ptuple

4 13 14 15 16

(

1

3 C

to list of authors

)

0

=

4 18 28 1986 29

...

7

2

C

A

list