Integrating Database Applications on a High-Performance Personal Computer
R. Cattell, J. Donahue, W. Haugeland, J. Maxwell
Computer Science Lab, Xerox PARC
Palo Alto, California, USA
0. Introduction
The subject of this paper is the integration of components of a software system, to show a computer user a high degree of consistency and commonality between components.  For a variety of reasons, software typically exhibits less integration than one might desire.  Systems often evolve in a "piecemeal" fashion over years, and are built by a number of programmers.  Also, integration is difficult: a lower common denominator between the parts requires less design and coordination between programmers.  One typically finds that the different system functions are divided among what the user views as independent programs.
The Cedar project is an attempt to build a powerful programming environment for the use of the Computer Science Laboratory at Xerox PARC.  As part of this project, we have been working on the construction of a database system, a collection of database applications, and a set of application support tools.  The main point of our work has been to integrate the database applications so that the user does not see the applications as independent pieces, but as cooperating facilities that:

1.	coordinate in their use of the underlying database.  This we will call "internal integration"; the various applications making up the current "database system" must be able to communicate with one another, e.g. so that an application can be notified if a portion of the database has changed.  In a successful system, the user will be unaware of how this internal integration is performed; if it fails, however, he will be painfully aware of its absence.

2.	provide the user a uniform set of commands for performing operations.  This we will call "external integration"; it is what makes the various applications look less like a collection of independent programs and more like different aspects of a single system.  External integration is simplified by, though not impossible without, internal integration.
A number of database applications are important for our personal computing environment.  Electronic mail is a central component of the environment at PARC, where a large number of powerful personal computers are linked together by an internetwork of local networks and gateways.  One of the major uses of electronic mail is the announcement of events (meetings, lectures, etc.), so a calendar application is an important adjunct to the mail system.  An electronic mail application and calendar database application have been developed and are now in regular use, while their further development continues.  Another application is an experimental replacement for the "whiteboards" that we have on our office walls.  In this application, database entities and ordinary text can be displayed on the user's screen in the fashion of notes on a whiteboard; they can be moved around on the whiteboard to present just the spatial structure the user intends.  This "free form" sort of display is important in allowing users to tailor the structure of their information environments.  A telephone directory application and the beginnings of an "electronic notebook" application are currently under design.
We have observed two important characteristics of our applications that are important to the view of integration we have taken:
1.	Applications have no reason to share a simple common display format.  Thus, we have not designed a "forms editor" [Rowe and Shoens 1982] for developing application packages.  Each application has been developed to display information in the format most natural for its own purposes.  Thus the calendar system can display months much as they appear on a wall calendar, while the message system displays plain text.  When high-performance machines are connected to bitmap displays, it seems far wiser to use the medium of the display to present information in a familiar form, rather than forcing it into the contraints of some simpler or non-graphical format.  Indeed, the whiteboard application allows the display layout to be specified dynamically by the user.  
2.	Applications must allow entities to be related to one another in fairly unstructured fashion.  The applications are all replacements for common objects in our offices, so they have to have the same "unstructured" feel as our whiteboards, calendars and files of messages.  The calendar system clearly needs to be able to associate messages with calendar entries.
The database system upon which our work is built is described in more detail elsewhere ([Brown et al 1981], [Cattell 1983]); in this paper we will focus on the support tools and the design and implementation of the applications themselves.  For the purposes of understanding this paper, it suffices to understand the two primitive data types the database system provides: entities and relationships.  An entity represents a real or abstract object, such as a message, event, or person.  Relationships represent information about entities or connections between them; they are records whose fields are primitive values (Booleans, integers or strings) or database entities.  For example, relationships might specify a person's birthdate or spouse.  Every entity has a type; we call a type of entity a domain.  Entities also have unique names.  Every relationship also has a type (in essence, the types of all of its fields); we call a type of relationship a relation. 
In the next section, we describe the interface our family of applications provides the user and illustrate it with examples of several applications, showing in some detail their commonality and features.  In Section 2 we will then show how the system is integrated internally, making possible the external integration shown the user.  We will then briefly describe the implementation of our application development tools, and close with comments on the successes and failures of the current environment and some discussion of future directions for this work.
1. External Integration
The Cedar user sees the following environment.  The display is broken up into a (sometimes quite large) number of non-overlapping windows, some full-size and some iconic (the figures at the end of the paper give many examples of actual Cedar screens).  A pointing device (a three-button "mouse") can be used to move a cursor around on the screen and to select text or invoke operations (clicking a "button"); the three buttons on the mouse are called the red, yellow, and blue buttons.  Cedar provides a high-degree of concurrency in the operation of running programs; thus, the user can be reading his mail with one program while editing a file with another, while running the compiler to compile a third, etc.  To allow this concurrency without making life hopelessly confusing, the Cedar screen allows input to only one window at a time; the "input focus" must be set (using the mouse) before the destination for type-in changes.
The display paradigm used
Our application user interface paradigm is based upon three generic kinds of windows on the screen: displayers, editors, and queryers.  A displayer window 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 are displayed, along with commands such as Answer, Forward, and Delete.  An editor looks much like a displayer, but allows modification of 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 an 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 given constraints.  When the user invokes the Get command on a queryer, the entities satisfying the constraints are displayed and may be browsed or printed.  Each database application program implements displayers, editors, and/or queryers that are appropriate for that application.  For example, the message system implements message and message-set displayers, message editors, and message queryers.
Figure 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 1a is a message displayer, implemented by the mail application.  Figure 1b shows a month displayer, implemented by the calendar application.  Figure 1c shows a picture displayer, implemented by a simple image application.  Figure 1d shows a whiteboard displayer, used for spatial data organization.  And finally, Figure 1e shows a "default" displayer which is invoked when no particular application knows how to deal with an entity of a given type (in this case, a person).  We will return to the default displayer in Section 3. 
Figure 2 contrasts a displayer, editor, and queryer for messages.  We will refer to displayers, editors, and queryers collectively as "nuts".  A nut always has a unique associated domain (entity type).  If a nut is a displayer or editor, it is also associated with a single entity in the database. 
Most of the mouse buttons have common interpretations supported by applications.  For example, the yellow button always means "open", or "show me", regardless of application.  Figure 3 a-d illustrates how the yellow button may be used to browse through entities in the database, even across application boundaries.  This interpretation of the yellow button is also consistent with its common use in the Cedar system -- when the yellow mouse button is clicked over an icon, it "opens" to become a full-sized window.
While using the yellow button always "opens" the database entity to a full-size display, the user does not always want to open a new window; this proliferates windows on the screen.  Thus all applications obey the following convention for opening new windows when an entity is selected:  
1.	If an entity has been opened fron this window before and the 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 window on the screen for the selected entity.
The interpretation of other mouse buttons is illustrated in Figure 4.  The red button always means "select": a message in the message set in Figure 4a has been selected with the red button.  The blue button always means "extend selection": the selection made in Figure 4a could be extended to include several messages with the blue button.  If the red button and control key are both pressed, the object at which the cursor is pointing is deleted.  This could be used to delete the message in Figure 4b from the message set in Figure 4a.  If the red and shift buttons are both pressed, the object at which the cursor points is copied to the current input focus; this is useful for moving entities or text around.
Thus each button, in combination with the shift and control keys, has a common primitive meaning across all applications.  The complete interpretation of buttons is as follows.
 
  Button			Interpretation 
  Red				Select the entity or other value at the current cursor position
  Blue			Extend a selection made by red to the cursor position
  Yellow			Open a new displayer on the entity at the cursor position
  Control-Red	Delete the relationship at the cursor position
  Shift-Red		Insert the entity or string value at the cursor into the current input focus
  Shift-Yellow	Expand the selected entity in place rather than creating a new displayer
  Shift-Blue		Extend selection made with Shift-Red, i.e. insert several values
  Others			Currently application-defined
Each application also attempts to provide a consistent view of the underlying database by the automatic update of its display windows.  For example, if the DeleteMsg command on the message in Figure 4b is invoked, it will automatically disappear from the message set in which it appears in Figure 4a.  Any other message sets on the screen containing the message would also be updated.
Automatic updating of windows requires a good deal of skill in writing a single application (particularly to deal with the highly concurrent nature of Cedar).  To allow applications to share data, the database system provides the necessary paths by which the applications can communicate with one another.  We will discuss the mechanism by which updates are communicated in Section 2; the important point here is that the applications and their windows coordinate in such a way as to give the user a consistent view of the database.
In certain cases, it may be difficult or undesirable to maintain consistency of a window's display.  For example, if a window represents the result of evaluating a complex query, we probably do not want to pay the cost of re-evaluating the query on every update, unless an adequate incremental evaluation scheme can be developed.  Similarly, we may find it too expensive to rebuild windows whenever a transaction is aborted on a shared database (all of our applications thus far have involved private databases).  As we gain more experience with shared databases and queries, it may be necessary to invent a new mechanism such as marking certain windows as potentially invalid.
Some database applications
Our first application of the database system was Walnut, a collection of facilities for sending, receiving, filing, and querying electronic messages.  Walnut provides four kinds of windows visible to the user:
1.	Control window:  This window is the one that appears when Walnut is started.  It provides menu commands to fetch new mail, to create a new message form (item 4 below) and to create a new "mail file" (item 2 below, which we call a message set).  The control window also reports when new mail is available, the user's password is invalid, or any 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 initially inserted.  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.  Figure 3b illustrates a message set displayer.
3.	Message displayer:   This window displays a message in the database.  The menu of commands at the top include Answer and Forward, which produce an appropriately initialized instance of a message form (item 4 below), and Erase, which deletes the message, removing it from all message sets.  The user may yellow-select a message field to see a database item named there.  For example, selecting the "In-Reply-To" field causes the message to which this one replied to be displayed (another message display window).  Selecting the "Subject" or "Categories" items causes the corresponding subjects or 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).  Figure 3c illustrates a message displayer.  Figure 3d is the result of yellow-selecting the sender of the message in Figure 3c.
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.  Figure 2b illustrates a message editor.
Another database application now in preliminary use is Hickory, a Calendar/AlarmClock applications for recording appointments and reminding the user of them; it implements "event", "event-set", "day", "month", "week" and "year" entity displayers.  Hickory uses a hierarchy of event domains to define different types of events, such as meetings, seminars and trips.  The user may enter particular events or sets of periodic events (e.g., a seminar every Tuesday at 2 o'clock).  When the client views a particular day he sees the events scheduled for that day.
Another application, "Whiteboards", provides functionality useful in conjunction with all of the other applications.  The Whiteboard package provides a mechanism to organize arbitrary entities in a tree-structured, spatial dimension.  The user may browse by moving up and down a hierarchy of "whiteboard" displayers whose ultimate leaf nodes are non-whiteboard entities.  An example of a whiteboard display was given in Figure 1d.  Message and calendar entities, or arbitrary text may be placed on whiteboards.  Thus our system provides two kinds of browsing:
1.	"Ground-level" browsing in a network of relationships by selecting adjacent entities, e.g. selecting the sender of a message to get a displayer on that person, or selecting a day in a month to get a displayer on that day.  This basic browsing functionality, illustrated in Figure 3, is provided in all applications and in the default displayer windows.
2.	"Tree" level browsing by moving up and down a hierarchy of "whiteboard" displayers (an example of a whiteboard display was given in Figure 1d); this adds a vertical dimension to (1).  We call this "tree" level browsing,  although strictly the hierarchy could be a cyclic directed graph.
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, perhaps even photos.  Note there are both public and private versions of whitepages; the user would like to see both superimposed.
2.	Program database.  A database of Cedar 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.	Public/private notebook.  A database of one-sentence to one-page ideas, interconnected and indexed in a database of logical dependencies, bibliographic references, project notes, etc. 
The external integration of database applications is made possible by their coordination through a central manager for the displayer, editor, and queryer "nuts" the applications implement.  We call the nut manager Squirrel.  We describe the internal interface Squirrel provides to application programs in Section 2.  Squirrel also provides an external interface to the user; it implements the default displayer, editor, and queryer windows as well as providing other useful but application-independent functions.  We will describe these functions in Section 3.  
2. Internal Integration
High performance personal computers demand systems that exhibit a high degree of concurrency. Cedar users become annoyed with the same synchronous behavior found on the earlier Alto system.  The internal integration of such a system is a particularly difficult task.  For instance, in Cedar there are several files whose contents establish important properties of the system:  the file "User.profile" includes information about the name of the printer to be used when a document is printed and whether Cedar is to go into "idle" mode (putting up a blank screen) after some time without user actions. An obvious problem for the system designers is orchestrating the notification of all of the relevant programs of changes in these files -- one doesn't want to have to reinitialize the system simple to get the user executive or editor to respond to a different set of commands (a change that can be simply made by editing User.profile).  One of the advantages of using a database to communicate among applications is that there is now a common repository for changes to be registered, avoiding the problems of having to establish separate communication protocols among a large number of programs (requiring the editor to know, for example, that if the extension on the name of the file to be stored is ".profile" then the user executive needs to be notified).  Instead there must be a simple way for applications to tell the database system that they are to be notified when changes are made.  Since the database is large and will be used by many applications, this cannot be simply "tell me when any changes are made" but "tell me when changes are made to that portion of the database of interest to my application."  Providing this capability to database applications is one purpose of the Squirrel package.  Below, we discuss how Squirrel fits into the larger Cedar system and how it is used by applications to provide the necessary level of internal integration.

Cedar and its Components
The following are the major components that a database application can use as a base for development:
1.	The Cedar system itself.  Cedar includes a text editor, so that an application can deal with text just by setting or reading the contents of a window on the screen.  The window manager package provides tools for building fairly complex displays (like those seen in the figures at the end of the paper); a Cedar application can easily get a new command menu put on the screen or make a window in which the user can enter new text. 
2.	The Cedar database system, Cypress.  One important point about Cypress that makes it a particularly good tool for communicating among separate applications is that a Cypress database is self-describing; the database schema is also stored in the database.  Thus programs which deal with databases do not have to "hardwire" the database types and structure into their code.
3.	Squirrel, which runs on top of Cedar and Cypress, provides the tools for interconnection among separate applications.  Squirrel also provides a number of general-purpose database tools, including windows for simple browsing, editing and querying of the database and facilities for database dumping and reloading and for reorganization of the database schema.  Below, we will discuss the interconnection mechanism Squirrel provides; in Section 3, a more detailed discussion of the use of the other tools Squirrel makes available will be given.
It is worth pointing out using a common text editor with multiple windows provides a (rather weak) way of connecting applications; one can at least select text from one window and stuff it into another window.  This can be useful when one application does not want to be too closely connected with another.  For example, the current mail and calendar systems lack a direct means of taking a message and entering an event on a calendar; the mail system has been far ahead in its development and it would have been awkward to connect it too tightly to the calendar system.  But a user can easily select the pertinent information from a message and enter it onto a calendar.  In the near future that will become automatic.
Interconnecting Applications with Squirrel
A Cypress database consists of a number of segments; basically each application has its own segment.  This make is possible to put some firewalls between applications, so that while an application can run amok and clobber the data in its own segment, it cannot make it necessary for all of the segments of the database to be reconstructed upon a failure.  Applications communicate through Squirrel; they do this by registering themselves as the application responsible for the displaying or editing or querying of certain domains.
Displaying, Editing and Querying
The basic idea of Squirrel is that each application is responsible for certain domains of entities in the database; when an entity is to be displayed or edited or when a database query is to be performed on a particular domain, Squirrel passes on the request to any application that has registered itself for the domain.  Applications register themselves and call other such procedures through operations in the Nut interface.  (Interfaces are the connectors between programs in Cedar; a program may import an interface to use the operations that an implementor of the interface exports.)
Applications register themselves to provide the displayers, editors or queryers for a particular domain through the Register operation
Register: PROC
domain: ROPE,
display: Nut.DisplayProc _ NIL,
edit: Nut.EditProc _ NIL,
query: Nut.QueryProc _ NIL,
create: Nut.CreateProc _ NIL,
update: Nut.UpdateProc _ NIL,
notify: Nut.NotifyProc _ NIL ]
The Register operation takes as its arguments the name of the domain (ROPE is the name for "string" in Cedar) and a list of procedures that are to be called when
1.	entities of the domain are to be displayed or edited or when a query is to be performed on the domain (the DisplayProc, EditProc and QueryProc),
2.	new windows are to be created for displaying entities from the domain (the CreateProc),
3.	the database is updated (the UpdateProc), and
4.	a transaction open, close, checkpoint, or abort is about to occur (the NotifyProc).
If any of the display, edit, query or create arguments are left unspecified, then a default procedure is supplied by Squirrel.  Also new registrations supercede old ones, so the operations registered for a domain can change during the execution of an application (this is particularly important when debugging a new application, as we discuss further below).
The display and edit operations take as arguments the entity to be displayed or edited, the window (Viewer) to use for the displayer or editor and an additional argument that is used to pass application-dependent data.
DisplayProc: PROC[e: Entity, viewer: Viewer, init: REF ANY]
EditProc: PROC[d: Domain, eName: ROPE, viewer: Viewer, init: REF ANY]
REF ANY in Cedar is a "wild-card" type that can be used to pass any type of argument (this is done in a type-safe fashion, however; the argument must be coerced to a particular type before it can be used, and an automatic check for type-correctness is done at that time).  The only difference between DisplayProcs and EditProcs is that DisplayProcs take a database entity as an argument, while EditProcs take the name and domain of an entity as arguments; this allows an editor to handle the case where the entity does not yet exist in the database.
The display, edit and query procedures that an application registers are invoked through Display, Edit and Query procedures.  The purpose of these procedures is two-fold:
1.	They call either a registered procedure or a default one if none has been registered; thus, applications need know nothing of other applications that are running in the same environment.  To display an entity, an application simply calls Display; if an application is currently running that has registered a special display procedure for the domain, it will be called; if not, then the default displayer will be used.
2.  	The Squirrel procedures also handle allocation of new windows.  The arguments of Display (for example) are:  
  Display: PROC[
  e: Entity, parent: Viewer, method: Method, init: REF ANY]
     where Method is defined as:
  Method: TYPE = {replace, oneOnly, any}

As mentioned in the previous section, it is not always desirable to allocate space for a new window on the screen; thus Display uses the following algorithm to choose a window in which to display the entity.  If the method is "replace", then use the parent window to display the new entity.  If the method is not "replace" and parent is not NIL, then use the last window spawned from the parent (thus, an application that puts up a window with many buttons that each cause a different entity to be displayed does not have to manage by itself the proliferation of windows that would result if a user selected several of these buttons).  If the method is "oneOnly" and there is no previously spawned viewer for the parent, the look to see if there is already a viewer for this entity; if so, use it.  Finally, if none of the above obtain, create a new viewer.  By making some gross management of screen resources part of the semantics of Display and Edit, we free the application not only from knowing what other applications are currently also using the display, but from the very real problems of trying to limit the use of screen "real estate".  More importantly, centralizing the Display algorithm gives the external integration that we described in the previous section.
Updating the database
To present a consistent view of the database to a user, an application may need to change its display to reflect a new state of the data; of course, when several applications are running on the same database, an individual application cannot know when such changes of state have occurred.  Even within a single application, there may be a need to communicate updates between procedures handling each window.  We introduce an Update procedure to handle this function.
Not all changes to the database require cross-application notification, so an application must call Update to announce a change in the database that is of possible importance to other applications.
Update: PROC[updateType:UpdateType, tuple:Relship]
where
UpdateType: TYPE = {create, destroy}
and tuple is a relationship of the database.  Everyone who has registered an update procedure for a domain referenced by the tuple will be notified of the change, to allow them to update their current display window (or anything else they may wish to do).
To make it easy for application to find all of their display window, the we also provide a procedure to enumerate all of the database application windows currently on the screen.  The procedure EnumerateNutList takes one argument:
EnumerateNutList: PROC[proc: PROC[n: NutRec]]
RETURNS [continue: BOOL]]
where a NutRec contains all of the information Squirrel needs to perform its management functions (it has a pointer to a window, and the name and domain of the entity being displayed or edited in it).  EnumerateNutList calls its procedure argument until the result returned is FALSE; typically, this procedure collects a list of interesting windows and then performs some action (like recomputing the contents of the windows).
Starting/Stopping Applications
Another time when applications need to communicate with each other is when a transaction is aborted, opened, or closed.  For example, some applications fork processes that continue to run waiting for the database transaction to be re-opened, e.g. when Cedar is idle.  The notify procedure supplied when an application registers itself is called when such an event is about to occur.  
NotifyProc: TYPE = PROC[whyNotified: NotifyType];
NotifyType: TYPE = {afterOpen, beforeClose, afterAbort}
Notify procedures are particularly important in allowing an application to store cached data in the database (before a Close) or to rebuild caches (after an Open). 
The original need for the transaction notify procedure was largely because our database system does not yet implement multiple transactions for one user (only for shared databases).  Thus multiple applications running on the user's machine must cooperate in the use of the same transaction.  However it sometimes desirable for multiple applications to cooperate in the use of a transaction even when multiple transactions are available, because a set of updates represent a single logical user action; thus our notification procedure may remain even after our database system's limitation has been remedied.
We now discuss some of the integration problems in particular applications, and their solutions using Squirrel.
Walnut
As seen from Squirrel, Walnut is responsible for entities in two database domains, Messages and MessageSets.  Although Walnut is relatively self-contained (the operations it provides involve only messages and message sets), there are several aspects of Walnut that demand cooperation with other database applications; we will focus on only two of the most interesting of these.
Because storing long strings in the database is expensive (and because mail users are quite unhappy about lost messages), Walnut keeps a log of message bodies read and Walnut commands performed.  In fact, the Walnut portion of the database can be completely reconstructed from the log.  Walnut also stores information about the log in the database, so that an incremental recovery can be performed when a crash occurs.  Since not all applications require the same "fail-safe" reliability of Walnut (less data is entered between commits in the calendar system, for example, so a crash is less serious), it is unreasonable to provide a general logging facility that everyone must use.  The performance overhead would be too high.  However, for applications to build their own logging mechanism, it must be guaranteed that they will be notified of every transaction open and close so they can assure consistency between their portion of the database and their log.
One of the problems of integrating database applications is deciding who is responsible for getting things started and stopped.  In our scheme, the user can open or close a transaction and know that all other applications will get a chance to clean up.  In our early work, Walnut was the most important application using the database, and the user typically found it most convenient to start and stop all applications through Walnut, although the Squirrel window could also be used to do this.
Whiteboards
Whiteboards are almost entirely a study in application integration.  They provide integration not only between database applications, but with the entire Cedar system: any Cedar icon can be placed on a whiteboard.  Since Whiteboards may be applied across application boundaries, they have been incorporated as part of Squirrel.  Whiteboards work as follows.
Any window in Cedar can be made iconic; the icon used can be a fixed bit pattern (a 64-bit square) or can be produced by a program (for example, one of the icons on most displays is a clock that is updated each minute).  The icons, which appear in one or more rows at the bottom of the display, can be selected; once selected, a small set of operations can be performed, e.g. deleting, moving, or opening to full window size.  The menu on whiteboard windows includes the command "AddSelected," which takes the currently selected icon and adds it to the whiteboard display (and changes the database to reflect the addition).
The Whiteboard package is an interface between the world of Cedar windows and the world of database entities.  In fact, the Whiteboards are also allowed to contain Cedar objects like text files and the control windows of running programs (like Walnut) that are not usually entities in a database.  Squirrel automatically creates database entities to represent text files or programs when an attempt is made to add one to a whiteboard; when one of the entities is "opened", the corresponding file is displayed or the program is loaded if it is not already running.  Squirrel provides a RegisterTool procedure by which an application program can put into the database the necessary instructions for loading a program when the corresponding entity is selected:
  RegisterTool: PROCEDURE[name, impl, instructions: ROPE _ NIL];
where the name is the name of the window (names are displayed at the top of a window in a "herald line", impl is the name of the program file implementing the tool (what has to be loaded if the user tries to run the program from a whiteboard) and the instructions are human readable instructions for getting the tool (for example, on what file server the tool can be found if it is not on the local disk).  Thus, one can store in the database any Cedar entity that can be displayed on the screen by any program.  A very important use of this is to build whiteboards that contain pointers to frequently used files, so that one does not have to perform long searches for "something that contains *Mumble*.bcd".
Hickory
Hickory, the calendar system, manipulates a number of types of entities: Days, Weeks, Months, Years, Events and EventSets.  Automatic update is a particularly important property for Hickory; people expect to always see up-to-date versions of their calendars.  This means that editing an Event (adding it to the database or changing its time) may cause many other windows on the screen to change.
It is possible using Cedar to allow the module that performs the redisplay of calendars on update to dirrectly access the code that causes calendars to be displayed.  However, using the Squirrel Display and Edit procedures, this is not necessary; an application can also reference other parts of itself using Nut.Display and Nut.Edit.  And there are good reasons for doing this.  If all calendars are displayed through calls to Nut.Display, then we don't have the problem that any (even cosmetic) change in the code that produces the calendar displays can cause recompilation of large pieces of the system.  Using the Nut interface even when it is not absolutely essential makes it possible to treat a large system as itself being composed of independent parts that are integrated using the Squirrel tools.
The other main problem that Hickory faced was that it is more like Whiteboards than Walnut in in being not at all self-contained; users want to be able to associate messages (and other database entities) with their calendar entries and with the calendars themselves.  Thus, we adopted the same user interface as Whiteboards for putting a database entity on an event display (or on a calendar). 
3. Application-independent Functions
In the previous two sections we explained how we achieve integration in our system:  through the cooperation of programmers in following a set of uniform conventions for user-interaction and the Squirrel software that simplifies and encourages that uniformity.
In addition to its function to provide central registration and uniformity among database applications, Squirrel provides general application-independent functions to assist both the user and application builder.  These include:
1.  The default displayer, editor, and queryer windows.  These are useful to an application-builder for debugging, and to an end user for maintaining and examining databases for which no application has been built (e.g., an address book).
2.  A facility to dump all or part of databases to disk files in an application-independent human-readable textual form, and to load databases in the same format.
3.  A facility to erase all or part of a database, e.g. in preparation for reloading it from a dump file.
4.  Global functions on databases, e.g. opening and closing database transactions.
5.  Displayer and editor windows for data schema entities, i.e. the data types.  These allow the actual types of entities and types of legal relations between them to be modified.  Existing data is automatically updated to conform to the new structure.
The Squirrel window on the screen allows the user to invoke these operations; it appears as in Figure 5.  The buttons at the top of the window provide the following functions:
1.	Reset: aborts the current database transaction.
2.	Save: commits the current database transaction.
3.	Open: opens the new database specified in the Database field.
4.	Close: closes the current database.
5.	Dump: dumps all or part of a database to a disk file.
6.	Load: reads a disk file produced by Dump into the current database.
7.	Debug: bypasses the registration scheme, causing Squirrel rather than application displayers to be used.  The current set of registered applications is remembered and is restored upon applying Debug again; thus, it is possible to run an application for a while, stop to inspect portions of its database to determine if the application is performing satisfactorily and then resuming normal operation.
8.	EraseDomain(s), EraseRelation(s), and EraseAll can be used to erase all or part of a database.
The three buttons labelled Display, Edit, and Query create new displayer, editor, and queryer windows respectively.  Display and Edit require that both the Domain and entity Name fields be specified.  For Display, the entity must already exist.  Query uses only the Domain field.
An instance of the default entity displayer was illustrated in Figure 3d.  It shows the domain and name of the entity displayed at the top of a window, and all the relationships in the database which reference that entity are shown as the main body of the window.  The relationships are displayed in the form
 relation  attribute1: value1  attribute2: value2 ... attributeN: valueN
where relation is the relationhip'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.  As with other displayers, the user may select an entity value with the 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.
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 a 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.  In addition to the relationships shown in the main body of the default editor window, the editor window also provides a field at the top of the window used to change the name of an entity or to save the edits to the current entity and open an editor window on a new 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 ProcessQuery 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 [Zloof 1975].
In addition to displayers and editors on ordinary data items, Squirrel implements special displayers and editors for domains and for relations.  Thus the user may examine or modify the data types as well as the ordinary data.  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 all of the entities of the domain sorted by name.  The user can scroll or yellow-select the entities.  The editor for a domain allows the user to change the sub-types and super-types.  The displayer for a relation shows a table whose columns are labelled with the names, types, and uniqueness constraints for the relation's attributes.  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 an entity-valued entries to open displayer windows.  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).
4. Results and Conclusions
We have discussed the concepts of internal and external integration in a family of database applications implemented on a powerful personal computer.  To date our databases contain electronic messages, calendars, pictures, spatial layout information, and miscellaneous less structured data.  We expect to learn more about the integration of applications as our experience continues; however we can already make some conclusions from our implementation.
The internal integration provided by communicating through the database system and a centralized application manager have not only simplified the task of building applications, but naturally make them more externally integrated.  Few lines of code are directly concerned with handling the internal integration, but the commonality has a large impact.  The common code has been redesigned more than once as we find better ways to integrate the parts.
We allow applications a fair amount of freedom in the format of their display and interaction.  However, a few common primitives in the interface have had a large impact on external integration.  Just as the command "delete" could be unified across a variety of applications using a conventional display, a common "delete" mouse button can provide the same function across a variety of applications in a window-based environment.  The user thus has less to learn when dealing with a new application, and is less apt to be confused by different conventions for what is logically the same operation viewed at a higher level.  The authors conjecture that productivity is increased by the ability to map operations onto actions at a level the user can exercise without thinking about it.   
Sharing a database system provides other benefits.  General-purpose tools can be used to browse, query, or edit a database.  An application need only provide specialized tools for these functions where there is a significant benefit from doing so.  Or, the general tools may serve as temporary stopgaps during the development of new applications.  
Note that we have generally encoded knowledge of the semantics of an application's data schema in application programs, providing a powerful user interface as a result.  For example, a telephone directory application may understand the syntax of 7-digit USA phone numbers and area codes, and provide automatic defaults and error checking.  To the extent that knowledge may also be encoded in the database itself, however, it becomes possible to provide a powerful interface without ad hoc code for each application.  This is not always the most practical solution, but is quite useful when data from a number of applications have analogous semantics.  The utility of our general-purpose tools was enhanced by the fact that our database system provides a higher-level data model, encoding more semantics of the data than most database systems. 
We found the general-purpose Squirrel facilities quite adequate by themselves for some kinds of database applications, such as personal databases of addresses or wine tastings.  The default Squirrel displayers and editors also proved useful to database application programmers, to examine and modify a database in the process of testing and debugging application programs.
Our research was greatly simplified by the use of high-performance personal computers, allowing us to concentrate primarily on functionality rather than speed or space in our experiments.  The primitive operations, such as displaying a message in a message-set or deleting an entry on a whiteboard appear essentially instantaneous on our machines despite the fact that flexible general-purpose graphics and database packages are invoked.  We believe, however, that except for inherently expensive operations such as complex queries, our simple interface could be implemented with quite adequate performance on any personal computer with a bitmap display.
There are several areas where we see the need for future research, either by ourselves or others:
1.	We continue to find better or more complete ways to externally integrate applications, as we note analogies between their functions.  For example, many applications deal with sets of objects, and more uniform conventions for dealing with sets are desirable in our system.  The spatial organization and manipulation of objects also deserves further experimentation.
2.	Although we have learned a fair amount from our current few applications, there are many other kinds of data a person could manipulate in a database.  We anticipate that other applications will uncover new problems and possibilities, and will also further increase the payoff of integration, simply in scope of the commonality.
3.	Our database system does not yet provide multiple atomic transactions on the same machine although data may be shared across multiple machines.  In order to properly interface applications sharing data on a single machine, we plan to enhance the functionality of the database system.
4.	Our database system does not yet provide a general optimizing query processor, instead requiring that the bulk of query processing be written in the application code.  The demand for such a query processor will expand as the desire for more complex queries increases.
4. References
Brown, M., Cattell, R., Suzuki, N. "Initial Experience with the Cedar DBMS", ACM SIGMOD Proceedings, 1981.
Cattell, R. G. G."Design and Implementation of a Entity-Literal-Relationship Data Model", CSL report to appear, Xerox Palo Alto Research Center, 1983.
Shoens, K., Rowe, L.  "A Form Application Development System", Proceedings ACM SIGMOD Conference, Orlando, 1982
Zloof, M. "Query By Example",  First International Conference on Very Large Databases, 1975.






�ʖ
"IFIP" style˜Ititle˜IIauthor˜l
head˜Ibody˜îNš
œè˜èIitemš
œÉ˜ÉOš
œâ˜âNš
œ«	˜«	N˜O˜þO˜ìNšœôÏeœ�œŽ�	œ �œr�œ˜ÆNš
œ®˜®—˜Nš
œ¤˜¤Mš
œ˜Nšœd�
œ�œ�œ¶ÏiœÉžœï˜€Nš
œ»˜»Nš
œª˜ªNš
œ‚˜‚šœ�
žœœ
˜ Ošœožœb˜×
O˜\—Nšœó�œN˜ÈNš
ϡ
˜°
ITable2šÏbœµ˜ÐNšœ^�œ’˜€N˜”N˜¥Mš
œ˜˜Ñ
OšœžœØ
žœ�
˜„Ošœžœ«˜ÃOšœžœð˜…Ošœžœþ
˜�—N˜®˜¯O˜ãO˜¡—N˜€
Ošœž
π
˜Ñ
Ošœžœ¥˜¸Ošœžœ 
Ÿ
˜»
N˜²—˜N˜­˜N˜eO˜±Oš
œö˜öO˜¡N˜Ï—˜*Nšœ+�œß˜’˜ NšœO�œÈ
�
œsÏfœU�œI�œ˜ÌNšœt œ
˜†
Iexampleš
 Í
˜Í
NšœF œW˜¡
Ošœn œ œ 	œ˜“
OšœN 
œ˜ZOšœ  
œ˜0OšœJ 
œ˜VNš	œ œ œ œ œº˜æN˜Ú
Qš
 ;˜;Qš
 E˜ENš
 œ¦ œ œ
 œ/ œ“
˜¥NšœY œ œ œ:˜ª
Ošœñ
 œ¬
˜¤š
œr˜rQš <œ ˜LIcontinuation˜ Qš
 )˜)RšœÕ œ¡˜ù	——˜Nšœ© œ#˜ÒN˜Å
Qš
 2˜2R˜Qš
 $˜$Ršœ œö
˜ÿ
Nšœ#�œ¾
˜æ
Qš
 G˜GR˜ª—˜N˜€Qš
 1˜1Qš
 7˜7Nš
œ¤
˜¤
Nš
œß˜ß——N˜o˜N˜ùNšœV�œå˜ÁN˜í—˜Nš
œå˜åNšœ®�œ¹˜ïNš
œõ˜õNš
 @˜@Nšœ
 œ[ œ×˜Ä—˜Nš
œ‹˜‹N˜¦N˜Š——˜$N˜„N˜ä
Oš
ϔ
˜î
O˜¢
O˜iO˜RO˜ü
N˜¯
Oš
œ2˜2Oš
œ2˜2O˜@O˜&O˜8O˜FO˜’O˜aN˜—˜´Nš
ÏoH˜H—Nšœ¡œ'¡œ·˜üNšœ§
žœÐ˜ûNš
œ­˜­Nšœ¾
�œù˜¼
—˜Nšœ"�œ�œ�˜ÄN˜ÁN˜’N˜ÜN˜ËN˜ôN˜ŽN˜aO˜ïO˜ÊO˜žO˜Ž—˜
N˜jN˜–
N˜oN˜\—M™M™M™M™M™M™—…—ÆîËý