Page Numbers: Yes X: 530 Y: 10.5" First Page: 87
Columns: 1 Edge Margin: .6" Between Columns: .4"
Margins: Top: 1.3" Bottom: 1"
Line Numbers: No Modulus: 5 Page-relative
Even Heading:
DESIGN AND IMPLEMENTATION OF A RELATIONSHIP-ENTITY-DATUM DATA MODEL
Odd Heading: Not-on-first-page
DATABASE ENVIRONMENT AND APPLICATIONS
7. Database environment and applications
7.1 Database environment
Along with the development of the Cypress DBMS, adding the Model level facilities to the former Cedar DBMS, we built a system named Squirrel to provide some general-purpose database tools and some level of integration between database applications. Several applications of the database system have been developed. These applications include Walnut, a database of electronic messages, and Hickory, a calendar/appointment database.
Squirrel provides the end user with tools to perform a number of basic database operations. These tools include:
1.A browsing window to examine database entities and relationships.
2.An editing window to modify database entities and relationships.
3.A simple query window to search databases.
4.A facility to dump databases in textual form, and subsequently reload them. The external form is human-readable text, and contains the database schema as well as the data.
5.A facility for examining and modifying the database schema, automatically re-organizing existing data for simple schema changes.
These five basic functions may provide all a user requires for simple kinds of database applications. For example, for some personal databases (a wine database, and a database of phone numbers and addresses) we have found the Squirrel tools useful in and of themselves. Squirrel is also used by database application programmers to examine and modify a database in the process of testing and debugging application programs.
In addition to the facilities directly provided the end user, Squirrel provides facilities for application programs. Squirrel’s function in this regard is to encourage a consistent and integrated user interface among the various applications. The goal is a confederation of database facilities as opposed to monolithic independent programs. Squirrel provides some convenient procedures for common database operations and Cedar Viewers operations, common conventions for the user interface, and a mechanism for applications to communicate with one another when data is displayed and updated.
The user interface paradigm we use provides one Cedar Viewer on the screen per database entity, an object-oriented menu of commands upon a database entity, and a consistent interpretation of user selections on the screen. The paradigm is based upon three basic types of application windows: displayers, editors, and queryers. A displayer displays a database entity, provides a menu of commands upon it, and shows the information the database contains about the entity. For example, for an electronic message displayer, the message’s header and body would be displayed, along with commands such as Answer, Forward, and Delete. An editor looks much like a displayer, but allows the user a form with which to modify the information about the entity, and usually has a different set of commands. For example, a message editor is created in response to a NewForm or Answer command in the Walnut system; the user fills in the fields and invokes the message editor’s Send or File command. A queryer also looks like a displayer and editor, but the user may fill in the fields with values, boolean expressions of values, or other application-interpreted information; the queryer represents all entities in its domain which satisfy the constraints. When the user invokes the Query command, the entities satisfying it are displayed and may be browsed or printed.
Each database application program, such as Walnut or Hickory, registers itself with Squirrel by passing procedures to be called when an event of interest to the application occurs. The application may register a displayer, editor, or queryer procedure to be called when the user requests one for a particular domain. Walnut registers such for the message domain, for example. An application may also register itself to be called when certain database relations are updated, so that it may update its display.
Figure 7-1 illustrates a variety of types of displayers. Note how each application takes best advantage of the display for the particular type of entity involved. Figure 7-1a is a message displayer, implemented by Walnut. Figure 7-1b shows a month displayer, implemented by Hickory. Figure 7-1c shows a picture displayer, implemented by a simple image application. Figure 7-1d shows a relation displayer, implemented by a data schema display package. Figure 7-1e shows a "whiteboard" displayer, used for spacially organizing and accessing entities. Figure 7-1f shows a "default" displayer which is invoked when no particular application deals with the given domain (in this case, the Organization domain). Squirrel implements the default displayers, whiteboard displayers, and schema displayers.
Figure 7-2 contrasts a displayer, editor, and queryer for messages.
Figure 7-3 illustrates one way in which the collection of database applications may appear as an integrated collection of facilities to the user, showing successive windows on the screen as the user browses from a "Whiteboard" display, to a "Message Set" on that whiteboard, to a "Message" in the set, to the sender of the message. The user crosses application boundaries in going from one kind of entity to another, but the action to browse (pointing with the mouse and pushing its center button) is the same throughout.
Squirrel, Walnut, and Hickory will be more fully described in a future report. To put the database work in context, however, we will summarize Squirrel in Section 7.2 and the applications in Section 7.3.

7.2 Database tools
A Squirrel window on the screen provides the user with the basic database functions, such as commiting or aborting a transaction, dumping or loading a database, or erasing portions of a database. The Squirrel window also allows the user to explicitly invoke a displayer, editor, or queryer on a particular domain or entity. If no application has registered itself for the given domain, Squirrel invokes its default application-independent displayer, editor, or queryer when the user requests one.
The default entity displayer shows the domain and name of the entity displayed at the top of a Cedar Viewer window, and all the relationships in the database which reference that entity are shown as the main body of the window. An example of such a window is in Figure 7-3d. The relationships are diplayed in the form
relation attribute1: value1 attribute2: value2 ... attributeN: valueN
where relation is the relationship’s relation and the attribute: value pairs specify the values of its attributes. The attribute which references the displayer’s entity is not shown, as it is normally redundant (all of the relationships in the displayer for an entity have at least one attribute which reference the entity or they would not be displayed). The other attributes are displayed in the obvious way for string, integer, and boolean values. For entity values, the name of the entity referenced is displayed. In addition, for entity values, the user may select the entity with the center (yellow) button on the mouse, causing a displayer to be created on the screen for the selected entity. This selection with the yellow-button provides the basis for browsing, and is supported by Squirrel displayers as well as application displayers.
The default editor window also shows the domain and name of the entity being edited at the top of the window. However it differs from the default displayer in that an editable form is provided in the body of the window for the entity, showing not only those relationships which already reference the entity, but "blank" relationships for relations which could potentially reference an entity of its domain. A "blank" relationship appears as a relationship in a displayer, but the values are given as blank fields that can be filled in by the user by selecting the blank with the red mouse button and typing. If the editor window is on a new entity (one that previously did not exist in the domain), then all the relationships shown will be blank ones. Special combinations of mouse buttons invoke special commands on the blank relationships: creating a new blank relationship for a particular relation, explanding the blank relationship to show the types expected of the fields, or specifying whether the system should automatically create an entity when a field value is filled in with an entity name that does not exist in the appropriate domain. Menu buttons at the top of the editor can be used to change the name of an entity or merge it with another entity.
The default queryer window has a form similar to an editor window, except that only a domain name is shown at the top of the window. The queryer window, unlike an editor window, represents any number of entities in a domain which satisfy a query. The query is specified by filling in the form fields with expressions that specify the desired values of the fields. The expression may include boolean ORs (written as "|"), and also ranges of values (written using "~", e.g. "5~11"). After the form has been filled in and the user uses the window’s Query command, the queryer opens a new window on the screen displaying the names of the entities which satisfy the query. The client may scroll through the entities, or select one of them with the yellow mouse button to open a displayer on it. Note that except for the form in which the answer is examined, this queryer window is similar to the Query-by-Example system of Zloof [1975].
In addition to displayers and editors on ordinary data items, Squirrel implements special displayers and editors for domains and for relations. The displayer for a domain shows the attributes in the data schema which can reference an entity from that domain, the sub-types and super-types of that domain, and the entities of the domain sorted by name. The user can scroll or yellow-select the entities. The editor for a domain shows only the sub-types and super-types, and allows the user to change these. The editor will automatically copy entities and rename domains if necessary to achieve the effect of a requested change (because the underlying database system does not allow defining sub-types of a domain that already contains entities). The displayer for a relation shows a table whose columns are labelled with the names, types, and uniqueness constraints of the relation’s attributes. An example of a relation displayer is shown in Figure 7-1d. The rows of the table show all of the relationships in the relation. Again, the user may scroll through the relationships, and may yellow-select attribute values that are entities to open a displayer window. The editor for a relation shows only the attribute names, types, and uniquenesses, and allows the user to change these. The user may also delete attributes of the relation or create new ones; the relation editor will automatically copy all the relationships into a new relation with the same name, since the underlying database system does not allow changing attributes of a relation after relationships exist.
Squirrel and application programs support a common interpretation of mouse buttons for the user. This common interpretation is as follows:
ButtonInterpretation
YellowOpen a new displayer on the entity at the current position
Red
Select the entity or datum value at the current cursor position
Blue
Extend a selection made by red to the current position
Ctrl-Red
Delete the relationship at the cursor position
Ctrl-Blue
Extends the action of Ctrl-Red over a number of relationships
Shift-Red
Copy the entity or datum value at the cursor into the current input focus
Shift-Yellow
Expand the selected entity in place (show more information)
Shift-Blue
Extend selection with Shift-Red
Others
Currently application-defined
The yellow button was dedicated to the "show me" interpretation because this was deemed the most common operation upon a selection, to open up a new window on an entity. The user does not always want to open a new window, however; this tends to proliferate windows on the screen. The Squirrel windows and database applications currently follow the following convention for opening new windows when a user yellow-selects an entity:
1.If the user has yellow-selected an entity in this window before, and the new displayer window thus created is still on the screen, we re-use that window, replacing the entity that used to be displayed in that window with the selected one.
2.Otherwise, we create a new entity displayer on the screen for the selected entity, in non-iconic form on the left-hand side of the user’s display screen.
The interpretation of the mouse buttons was chosen to be as compatible as possible with existing interpretations in the Cedar Viewers environment. There is in fact some overlap. For example, one can select an entity by selecting the entire window (or icon, if in iconic form) for its displayer. It can then be used by a command, e.g. to add it to a set of entities in another window.
All of the operations afforded the user by Squirrel are also available to client programs, through a Cedar Mesa interface called "Nut." The Nut interace is also the one through which application programs register themselves with Squirrel, through the Register operation:
Register: PROC[
domain: ROPE,
display: DisplayProc← NIL, -- to make displayer for entity in domain
edit: EditProc← NIL, -- to make editor for new or old entity in domain
query: QueryProc← NIL, -- to make queryer on domain
create: CreateProc← NIL, -- to create viewer for above (defaults to container)
update: UpdateProc← NIL, -- to call when database is updated
];
7.3 Database applications
Our first application of the Cypress DBMS was Walnut, a collection of facilities for sending, receiving, filing, and querying electronic messages. Walnut provides four kinds of Cedar Viewers visible to the user:
1.Control window: This viewer window is the one that appears when Walnut is started. It provides menu commands to fetch new mail, create a new message form (item 4 below) and create a new "message set" (item 2 below). The control window also reports when new mail is available, or an error is recognized by the Walnut system.
2.Message-set displayer: This window displays a list of messages, their senders, dates, and subjects. There is a special "Active" message set into which new mail is normally inserted. The viewer for this message set is automatically put on the screen, along with the Walnut control window, when Walnut is started. The user may display many message sets on the screen at the same time. Yellow-selecting one of the messages produces an instance of item 3 below, a message displayer. A menu of commands at the top allows removing messages from the message set and/or adding them to other message sets.
3.Message displayer: This window displays a message in the database. The menu of commands at the top includes Answer and Forward, that produce an appropriately initialized instance of a message form (item 4 below), and Erase, which deletes the message itself and removes it from all message sets. The user may yellow-select a message field to see a database item named there. For example, selecting one of the "Categories" items causes the corresponding message sets to be displayed (which enumerate messages on that subject or in that message set, which can in turn be selected). Selecting persons in the "To," "From," and "cc" fields causes the person to be displayed (phone number, office number, picture, or whatever the database happens to contain).
4.Message editor: This window displays a message form which the user can edit. Some of the fields will be initialized according to whether the message editor window was created by the "Answer," "Forward," or "New Form" commands.
5.Message queryer: This window also displays a message form which the user can edit. It represents all the entities with the values the user specifies in the fields he fills in. Value ranges may be specified. For example, the user might ask for all the messages with sender "Cattell" from last week, containing the string "Cypress" somewhere in the message body. When the user invokes the Get query command on the queryer, a new message set displayer appears on the screen containing the set of messages which satisfied the query. Although the messages in this message set are not actually stored in a database message set, the user may select and browse through messages in the window just as with any other message set.
Walnut uses a special text logging package, for two purposes. The current Cypress implementation does not deal efficiently with large string-valued attributes that are frequently created and deleted (the storage allocator is oriented towards objects less than a page in size). The text logging package allows Walnut to store the bodies of messages in a file, storing a pointer to the text body as a relationship connected to the message entity in the database. The text logging package is also used to maintain a record of every database-updating operation performed by Walnut, e.g. receiving a new message or adding a message to a message set. The log may be replayed to reconstruct a database after a crash, or in the unlikely event that an entire segment is destroyed. The ability to replay the log makes it unnecessary for Walnut to commit a database transaction after every operation. The text logging package used by Walnut is now being rewritten to incorporate it as an extension to the common database software, making it useful to all database applications.
Another database application now in preliminary use is Hickory, a Calendar/Clock database application for recording appointments and reminding the user of them. Hickory implements "event," "event-set," "day," "month," and "year" entity displayers. Hickory makes use of the database system hierarchy of domains to define a number of types of events, such as meetings, seminars, and trips. The user may enter particular events, or sets of events such as periodic events (e.g., a seminar that Hickory will automatically enter every Tuesday). When the client views a particular day or month he can see the events scheduled for that day or month.
A third application, "Whiteboards," has actually been integrated into Squirrel itself, because the functionality it provides is useful in conjunction with all applications. The Whiteboard package provides a mechanism to lay entities out in a tree-structured, spatial dimension. Consider three ways of moving around in a database by yellow-selection:
1.Browsing in the network by selecting adjacent entities, e.g. selecting the sender of a message to get a displayer on that person, or selecting some day in a month to get a displayer on that day. This basic browsing functionality is provided by convention in Squirrel and all applications. Let’s call this "ground" level browsing (Ground Squirrel).
2.Browsing in the network by moving up and down a hierarchy of whiteboards whose ultimate leaf nodes are non-whiteboard entities. This adds a vertical dimension to (1), and is currently provided by the addition of Whiteboards to Squirrel. We might call this "tree" level browsing: although strictly the hierarchy could be a directed acyclic graph, it’s easier to understand as trees (Tree Squirrel).
3.Browsing in the network by moving in a two dimensional continuum rather than the discrete vertical "chunks" provided by (2), as in Herot [1981]. All the database entities would be laid out in a two-dimensional plane, probably automatically according to their "closeness" (= the number or importance of the relationships between them). Zooming would be continuous rather than discrete as in (2). Let’s call this kind of browsing "flying": unlike climbing in a tree, there are no discrete horizontal or vertical levels (Flying Squirrel).
Only the first two kinds of browsing have been implemented, although some experimentation with the third kind might prove it valuable.
In addition to the applications already described, several database applications are under consideration for future development:
1.Whitepages. A database of people, organizations, phone numbers, addresses, and their photos. Note there are both public and private versions of whitepages, and the user would like to see both public and private information superimposed.
2.Program database. A database of Cedar Mesa program modules and interfaces, in which the user could query the locations of definitions and uses of procedures, types, and variables. This application would be interfaced with the program editor and compiler to automatically maintain the consistency of the database.
3.Super notebook. A database of one-sentence to one-page ideas, interconnected and indexed in a database of logical dependencies, bibliographic references, project notes, etc. Again, this could be both a private notebook or a shared notebook.
7.4 Summary
We have described some tools and applications built upon the Cypress DBMS. Applications have been in regular use for over a year, and have guided as well as demonstrated the utility of the Cypress data model and implementation. In the design of database applications, we have tried to achieve some uniformity so as to present the user with a confederation of information management functions rather than independent programs.
The reader may see how the data model has influenced Cypress applications and tools. The introduction of entities to the data model enabled the object-based user interface paradigm. The information about the types of relationship attributes and their relation keys is used in the default editor to check input and automatically create entities where required. The presence of entity names and the distinction between entities and relationships greatly simplifies dumping and reloading databases in a linear and human-readable form.