Please address comments on Ogre to: Please address inquiries on the use of Ogre to



(Objects Generated from Relations)

User's Guide

Version 1.0

Robert Keller
Jeffrey Polakow

NASA Jet Propulsion Laboratory

31 December 1998

Table of Contents



Ogre (Objects Generated from Relations) is a tool that enables users to convert information stored in a relational database to an object-oriented database (ODB) without requiring knowledge of SQL, the standard relational database access language. A graphical user interface enables the user to specify the form of the translation graphically.

The current version of Ogre is intended to target a POET object-oriented database. The relational database can be from any of a set of vendors supported by ODBC (Open Database Connectivity), such as Informix, Sybase, Oracle, etc., or the Java companion, JDBC.

Ogre provides the following functions:

The GUI enables a user to prescribe the conversion without requiring any knowledge of SQL, the relational query language. Based upon a graphical representation constructed on the monitor, Ogre generates the necessary SQL automatically and populates the ODB with the results of the SQL query. Alternatively, Ogre can simply display the results of the query, or route them to a text file.

The following diagram shows a diagram of Ogre and its principal interfaces.

Although Ogre does not require sophistication for its effective use, the present document does not attempt to be a tutorial on all of the concepts needed to understand what Ogre does. It is helpful if one has at least moderate knowledge of relational databases to understand Ogre's behavior from this document. A more basic tutorial will have to be the subject of another document.


Ogre Data Models

Ogre is based on a relational data model, an object-oriented data model, and a mapping between them. We describe these components next.

Relational Model

The relational model is the traditional one:

Object-Oriented Model

The object-oriented model is very basic:

While this model is basic, it is also universal in a certain sense. It allows us to extract data in object-oriented form from many different relational databases without necessitating the generation of new schema files for the objects, something which normally must be done in creating an object-oriented database.

The set of attributes for a type of object is referred to as the schema for the object. The structure of the resulting object-oriented database is determined by the set of schemas, as configured using Ogre.

It is not required that the same attribute names be used in the objects Ogre creates as were used in the relations. Ogre allows the user to rename the attributes. In some cases, renaming is necessary, as ambiguity would otherwise result. Ogre provides visual indications of those cases.


Mapping Relations to Objects

We now present the relational-to-object mapping in two steps. The first step is the mapping of a single relation to objects. The second step is a mapping of multiple relations, sharing common attributes, to objects.

Mapping a Single Table to Objects

Each object also has a schema attribute, which is by default the name of the original table, although this name can be modified by the user if desired.

Mapping Multiple Tables to Objects

A degenerate form of mapping for multiple tables would involve simply repeating the above single-table relation mapping once for each relation. However, this may not capture the intent of the original relational database. Typically relational databases distribute the description of single objects over multiple tables (through a design process known as "normalization"), and the attribute values of one or more tables would then be joined. We would like to recapture those joins in creating objects. As the exact nature of the join cannot be inferred from the tables alone, it is up to the user to specify the join, using Ogre's GUI.

Suppose there are two tables R and S with a common column attribute A and we intend that rows of R and S having the same value of A really designate the same object. We can indicate this intention in Ogre's GUI by making a connection between these attributes. In relational database terminology, this is conceptually a join of the two tables.

Ogre makes it possible to join any number of relations in this way. When the join describe the user's desired interpretation of the relations as objects, Ogre will present a query to the relational database to extract that information. Ogre will then generate the corresponding objects. The user also can inspect both the original relations and the resulting objects using the GUI.


Using Ogre

Currently Ogre runs as a Java application under Microsoft Windows NT. In the following, we walk the user through the various windows and functions in Ogre.


Ogre starts with three windows, typically one above the other. The user can control the opening placement of the windows, as well as other parameters, through the ogre.ini file. The opening windows are:

The following figures show the windows in a typical start-up. The label on the windows in their upper left-hand corner next to the steaming Java cup.


Control Widgets

Proceeding down and across from left to right, we will mention the function of each item in the menu Controls window:

A pull-down menu enabling an Ogre configuration (the graph and other associated information about the relational database) to be loaded or saved.

A pull-down menu containing built-in operators, such as <, <=, etc. that constrain the way relational database joining is done.

A pull-down menu giving options for creating numeric or string constants that can be used to build constraints.

Displays the most recent message relevant to the user. Most of these messages are also logged in the log window.

help msg:
Displays the function of each control as the mouse rolls over it. This feature can be toggled by clicking in the help message text area.

Mid URL:
The URL (Universal Resource Locator) for the middle-ware, currently Symantec dbANYWHERE, server currently used. This is a choice menu, and new choices can be added dynamically.

Prefix used to distinguish among user relations in the database.

The symbolic name of the currently-selected relational database. These names, and their associated databases, are filled for the user from a table created externally using a data-source administration tool.

The URL of the current relational database. Normally this is generated for the user by Ogre (through dbAnywhere), although it is possible to type in the URL directly.

A check-box and a text field. The text field shows SQL, such as is generated by Ogre automatically. The user can also enter SQL statements directly to access the relational database, if the check-box is checked. (Only one of the three checkboxes SQL, RDB, and ODB can be checked at any one time.)

RDB Tables:
The area below is a multi-choice menu from which the user can select tables of interest and display their structure in the Ogre canvas window. When the mouse is clicked in the canvas window, the chosen relations are laid out. Pressing the all button selects all relations, while pressing none unselects all relations.

ODB Schemas:
Each connected component in the graph constructed in the Ogre canvas determines a schema for the object-oriented database. These schemas are listed by name in the multi-choice menu below. The user makes selections on these schemas to cause objects to be generated. As with the RDB Tables menu, all or none can be pressed to make selection quicker.

to file:
Checking this box causes Ogre to put the textual data in a file rather than in a text window. The user is asked to give the file name at the time of pressing one of the previous buttons.

Separate Commit:
If this box is checked, it will cause Ogre to commit each object to the database separately, as opposed to all at once. For example, if the population of the object-oriented database were interrupted for some reason, the objects created would be retained if this box were checked, but otherwise would be lost.

If this box is checked, it will cause Ogre to add an attribute to each object indicated the name of the corresponding schema from which the object is derived. The schema name can function as a type indicator in an otherwise typeless system. The text field next to the tag checkbox indicates the name of the attribute to be used to hold the schema value.

If this box is checked, objects are assigned a numbering attribute value as they are created. The string in the following text field is used as the attribute name. The number in the text field labeled starting is ses the first number that will be used in numbering generated objects.

Interrupt button:
Pressing this during object-creation or data listing causes the attendant data transfer to be interrupted.

show SQL:
Pressing this button instructs Ogre to show, in the SQL window, the SQL statement that will be generated for the current configuration and selected schema. It does not actually use the SQL to get any data. If desired, the user can edit the SQL and submit it as a query by checking the SQL box. (It is expected that this form of usage will be relatively rare.)

show as table:
Pressing this button instructs Ogre to display the results of the configuration in text windows, one window for each schema.

populate ODB:
Pressing this button instructs Ogre to populate the object-oriented database with data as specified in the configuration in the Ogre canvas.

show & pop:
Pressing this combines the two functions of showing as a table and populating the ODB.

show ODB:
Pressing this shows the list of attribute values in the current ODB in a separate window or file.

Customize the initialization of some of the widgets may be done through the ogre.ini file, as described in Appendix A.

Loading a Relational Database

In the following, we will use as an example the relational database stores7 that is provided with the Informix Enterprise Server release. This a database for a sporting-goods store, containing 11 tables. Enter the user name and password for this database by selecting Password from the File menu.

Then enter prefix Administ and select the name stores7 from the RDB menu. Shortly thereafter, you should see the names of the relations appear in the RDB tables multiple-choice menu, as shown below.

The schema for this sample database is given in Appendix B.

Canvas Display

Click on two of the tables, say cust_calls and customer, from the tables menu.

The log should inform you that information about those tables is being loaded:

Then move the mouse to the Ogre Canvas window and click somewhere the upper left-hand corner. You should get a message that the database is being accessed and the canvas will change to a display similar to the following.


The oval nodes represent relations, while the rectangular nodes represent attributes of the relations to which they are connected. This display indicates that cust_calls has seven columns or attributes, while customer has ten columns or attributes. The names for the attributes are those given in the relational database itself. The dark box around the cust_calls relation indicates that this relation is selected. The selection is a group of nodes that can be moved as a unit.


Displaying Tables

Now suppose we wish to get an idea of what is in these tables. Notice that the Schemas menu shows two schemas, having the same names as the two tables. This is because each table forms a component of the graph by itself.

Select one or more of these schemas, then press show as table. The result will be shown in a window labeled with the name of the corresponding schema.

Generating Objects

A trivial application of Ogre is to generate objects directly from each relation, one object per relation row. In this type of usage, the attributes of objects are the same as the attributes (column headers) of the relations. There will be one "type" of object per relation.

In order to generate this form of object, select one or more schemas, then press the populate ODB button.

To check the results, press Show ODB, which will display the contents of the ODB in a text window.

Except for the addition of new objects, the object-oriented database cannot be modified from Ogre. However, a companion application called poetOgreDBaccess can be run from a DOS command line to clear all objects from the database, and run simple queries on it. This program is started by giving the URL of the object-oriented database on the command line. The program then presents its own command line, which has the following options:

Choosing the option of showing all objects produces the following sort of display:

If desired, we can then clear all of the objects from the database.

Manipulating Nodes

Relation and attribute nodes may be manipulated on the canvas. To move a single node, simply drag it with the mouse. The attributes stay connected to the original relation as a node is dragged. To move multiple nodes at once, the nodes must first be selected. Then dragging any one selected node drags them all.

To select multiple nodes, hold the shift key while pressing with the mouse. The outline color of a selected node darkens to indicate that the node is selected. A node can be selected or unselected, with other selections remaining invariant, by holding the shift key.

Another way to select multiple nodes is to press the mouse on the background area of the screen, then drag it. The rectangle thus formed will select nodes contained within. The shift-click technique can then be used to unselect nodes as desired.

Joining Attributes

When an attribute is dragged using the mouse to where it nearly coincides with another attribute of comparable type (numeric, string, etc.), the two attributes become joined as a single attribute, as shown below.

It is beyond the scope of this guide to explain the theory of joining. However, the impact on the object-oriented database that would be created is that the rows of joined relations will represent a single object.

Note that joining relations changes the schema to a name composed of the names of the joined relations. Each connected subgraph determines one schema for the ODB. So when two relations are first joined, there is one fewer schema than before. The new schema will, by default, have a name comprised of the names of the original schemas with two intervening underscores. For example, joining cust_calls and customer will produce cust_calls__customer. This name can be changed by the user.

Attributes can be unjoined by control-clicking the mouse button over the box (i.e. clicking while holding down the control key). One then has a choice, from the popup menu, of the following options:

remove the most currently created join.

change the name of the attribute (which will become the attribute name of any generated object) to one of the user's choice.

mask the attribute. This means that the user wants the attribute to remain on the screen, e.g. for joining purposes, but does not want the values of this attribute to appear in the resulting objects.

For attributes that are not joined, there is a different option instead of mask:
This means that the user wants to remove the attribute from the screen. As with mask, the values of this attribute will not appear in the resulting objects.

The difference between mask and hide then is that hide is a stronger operation: Joined attributes can be masked, but they cannot be hidden. Conversely, hidden attributes cannot be joined. This is so that all joined attributes are visible to the user.

There are two ways to view the attribute types in a schema:

The resulting schema window shows the types of each variable that will be used to populate the ODB.

The following is the list of options that appear when control-clicking on a relation node:

show schema
shows the ODB schema of which the current relation is a part

select all visible attributes
causes all attributes of the current relation to be selected

hide all attributes
causes all attributes of the current relation to be hidden

show all attributes
causes all attributes of the current relation to be shown (not hidden)

remove relation
removes the current relation node and its attributes from the canvas. If the relation was joined to other relations, it will be unjoined before removal.

Suppose we press populate ODB having selected the cust_calls__customer. The log will show the action taking place:

The information about query reflects the fact that an SQL query is presented to the relational database to extract the information from it. Objects are created from that information.

We can view the current object-oriented database by pressing show ODB:

Name Conflicts

When two attributes are joined, if there are other attributes with common names in the same schema, these will be highlighted, since they are regarded as conflicting. In other words, attempting to create objects using this naming scheme would cause ambiguities. These ambiguities must be resolved before Ogre will allow objects to be created.

The following example shows the phenomenon of name conflicts. Below, joining the two relations on stock_num has produced a conflict between the two instances of manu_code.

There are several ways to resolve the conflict. Each will have a different implication about the form of the objects ultimately created. Before pursuing an option, the user must understand the meaning of the relations and the intent of joining these particular attributes, to make sure that the result is meaningful when objects are created from the schema.

  1. Join the conflicting attributes. The attributes will be interpreted as if different names for the same underlying entities.

  2. Mask one of the attributes. Then only the unmasked attribute will appear in the resulting object.

  3. Hide one of the attributes. This has the same effect as the previous, but the attribute cannot be used later to join to any other attributes.
  4. Rename one of the attributes in the conflict. The attributes are interepreted as if they were the same name for different underlying entities. (If the attributes should have been joined instead, this can have the effect of producing a large number of superfluous objects.)

Each of these resolutions is now illustrated:

Alternative 1: Join the conflicting attributes:

Below we have joined the two manu_code nodes and the conflict has been resolved.

Alternative 2: Set one of the attributes to masked:

Below we have masked the left manu_code by control-clicking and selecting mask from the popup menu.

Alternative 3: Hide one of the objects:

Again, control-click to get the popup, then select hide.

The conflict is then resolved.


Alternative 4: Rename one of the attributes in the conflict:

Control-click one of the manu_code nodes, then select rename.

In the Rename Attribute window edit the name. In this case, we will just add a character 2:

The conflict is now resolved.

If the user wishes to view the original names of the attributes, this may be done by double-clicking the corresponding arc, as shown below.



Double-clicking again toggles the original name off.


Constraining the Selection of table entries

The user may add constraints to the selections from tables used to create objects. These are expressed graphically, but translate into SQL select conditions.

Examples are:

Constraint operators are handled similarly to relations. They are selected from the Operators pull-down menu at the top of the Controls window. Next to that menu is a Constants menu. Constants may be introduced by the user for the purpose of creating constraints. Below we show a constraint example. We wish to create objects from a join of the relations catalog and stock for which the unit_price is less than 9.99, the catalog_num is greater than 10000, and the cat_description is not equal to (<>) description.

The configuration for this query is as follows:

The result of this query is shown below as a table:

The reader can verify that the constraints are satisfied by the result given. Of course, a full inspection of the original tables would be required to verify that these are the only results satisfying the constraints.

We also show the result as objects:

Saving Canvas Configurations

Using the File menu at the top of the Controls window, the layout of schemas in a canvas can be saved to a file and later reloaded. Also, if the user selects a different relational database and changes have been made to the canvas, the user will be offered the opportunity of saving the configuration. The configuration file remembers the name of the relational database and its URL. Currently the configuration file does not remember the URL of the ODB.

Quitting Ogre

Leave Ogre either by selecting Exit from the file pull-down menu of the Controls window, or by clicking the close box in the upper right-hand corner of that window.


Object-Oriented Database Implementation

The object-oriented database is implemented in Java. The database class is called poetOgreDB, which is a wrapper for the POET class Database.

Each object is an element of the class poetOgreObject, which has as its main component an object of type MapOfStringToObject from the POET libraries. The latter is used to achieve a mapping from attribute names, which are strings, to objects of type poetPersistentValue. The latter is specialized to the following sub-classes:



double-precision floating point numerals


extended-precision integer numerals



The Java source code files may be consulted for a definition of the API for poetOgreDB and the other related classes.


Stand-Alone Database Access Program

Provided along with Ogre is a stand-alone program for accessing the POET database created by Ogre. Using this program, known as poetOgreDBaccess, objects can be searched by attribute value and displayed, modified, or deleted. The database can be displayed in its entirety or cleared. The program has a simple command-line interface with no windows. To use it, the user types:

java poetOgreDBaccess ... URL of POET database ...
Here poetOgreDBaccess is the name of a Java class, and is case-sensitive.


A previous version of Ogre, which stood for "Oracle-Grok Interface", was constructed by the authors in 1997 using Tcl/Tk and C++. That version used Oracle as the relational database and ObjectStore as the target object-oriented database. It was a complete redesign and new implementation an earlier version of Ogre with a different interface that originated as a Harvey Mudd College Computer Science Clinic project in 1996-97. That project was performed by Elizabeth Coleman, Chris Sloan, and Kevin Sours, with Robert Keller as faculty supervisor and Walter Bunch and William Lincoln as liaisons.

Grok stands for Graphical Representation of Knowledge and was introduced to us by Walter Bunch at JPL, who apparently ported it to UNIX® using Tcl/Tk. The GUI of the present version and our previous version of Ogre builds on the GUI ideas of another HMC CS Clinic project in 1995-96 known as Condor, which was performed by Will Ballard, Ingo Muschenetz, Jeff Polakow, and Amy Ward, with Robert Keller and Professor Josh Hodas as faculty supervisors, and Walter Bunch as liaison.

The authors wish to thank Dr. Lakshmi Rebbapragada of CECOM for facilitating the sponsorship of the project. We thank Lamark Johnson of JPL for his support during the project. The advice and suggestions of Dr. Nevin Bryant and James Hauge were invaluable throughout the project. We also thank John Rector for his evaluation and numerous suggestions for improvement.

Appendix A: Sample ogre.ini File

The following sample indicates all quantities that are settable in an ogre initialization file.
// User-modifiable Initialization file for Ogre
// Suggestion: Comment-out any lines you change, for possible example or reversion.
// Ogre looks for file named ogre.ini in the same directory as the executable.
// The format of this file is one attribute and one value per line.

// Comments begin with // and are on a line by themselves.
// DO NOT put comments at end of line.

// Generally the items are CASE SENSITIVE.
// Blanks count within values (e.g. for file names)!!!
// Only leading and trailing whitespace is trimmed.
// Tabs are allowed as whitespace.

// Most items are optional; if not specified, they default to none specified
// or some pre-defined value.

// addresses of DBAW servers
DBAW    dbaw://localhost:8889

// addresses of POET servers
ODB     poet://LOCAL/D:\\Program Files\\POET50\\bin\\poetOgreDB

// default user and password for RDB
userName    ... not shown ...
password    ... not shown ...

// default prefix for RDB
RDBprefix dba

// position and size of Control window
controlX        0
controlY        0
controlWidth    640
controlHeight   300

// position and size of Log window
logX            0
logY            345
logWidth        640
logHeight       125

// position and size of Canvas window
canvasWindowX       0
canvasWindowY       510
canvasWindowWidth   640
canvasWindowHeight  450

// The canvas is inside the Canvas window and
// is not necessarily entirely visible at one time.

canvasWidth         1500
canvasHeight        600

// amount by which to jog newly-created windows
jogX 20
jogY 20

// amount by which to space nodes when displaying multiple relations
xNodeSpacing 120
yNodeSpacing 0

// whether to allow intra-relation joins
allowIntraRelationJoin false

Appendix B: Schema for the stores7 Sample Database

Table names are shown in bold-face. Attributes are listed following, with the type of each element as it is treated by Ogre. The type "other" is not handled specially by Ogre and will be treated as a string.


























Appendix C: Configuration Notes

Ogre interacts with a number of different servers. This is a set of notes about configurating the servers, etc. for successful use. A Windows NT platform is assumed.

dbAnywhere Server

This should be started manually, by selecting Symantec dbANYWHERE Server. The Windows NT menu sequence of choices is: Start
Symantec dbANYWHERE
Symantec dbANYWHERE Server
It is not advised to have dbANYWHERE start automatically as a service. It is also not advised to start it using the dbANYWHERE Service Manager program.


POET Server

This must be running before there is an attempt to populate an ODB. It may be run as a service and started automatically.


Informix Server

This needs to be running if the stores7 or other Informix database is to be accessed. It may be run as a service and started automatically.


Sybase SQL Anywhere Server

This is used in some of the sample databases, such as sademo and Tutorial. It is not necessary to have this server running, as it will be started automatically if needed.


ODBC Logging

To achieve reasonable performance, ODBC logging should be turned off. The penalty for leaving it on may be slowed performance by a factor of several hundred.


ODBC Administration Programs

There are several different programs for administering ODBC and JDBC data sources, the term used to refer to a database at a specific site. These include: These tools essential create or modify files which establish the relationship between a data source name DSN (for example, stores7) and the actual database, its server, the access protocol, etc. The required information differs among vendors. In some cases, the tool also accesses and modifies information not stored in the obvious files, but in vendor-specific files.

Appendix D: Known Bugs

Bugs that are our fault:

Bugs that are apparently due to the underlying Java toolkit (currently Symantec Visual Cafe):

Additional features it would be nice to have:

Appendix E: Schema File for POET Database

  *  POET Java ODMG Binding
  *  Configuration file for poetOgreDB
  *  ptjavac.opt

oneFile = true

schema = poetOgreDict
location = SAME
oneFile = true

persistent = true
hasextent = true
schema = poetOgreDict

persistent = true
hasextent = false
schema = poetOgreDict

persistent = true
hasextent = false
schema = poetOgreDict

persistent = true
hasextent = false
schema = poetOgreDict

persistent = true
hasextent = false
schema = poetOgreDict


Graham Hamilton, Rick Cattell, and Maydene Fisher, JDBC Database Access with Java, Addison-Wesley, 1997. A thorough introduction to the JDBC API.

Joshua S. Hodas, Robert Keller, Jeffrey Polakow, Ingo Muschenetz, Amy Ward, and Will Ballard, Condor: A simple, expressive graphical database query language", Harvey Mudd College, Computer Science Technical Report HMC-CS-97-04, March, 1997.

Robert Orfali and Dan Harkey, Client/Server Programming with Java and CORBA, Wiley, 1997. Describes various layered client/server approaches, including for databases.

POET Software Corporation, Poet Java SDK Programmer's Guide, POET, 1997.

Symantec, Visual Cafe for Java User's Guide, Database Development Edition, Symantec, 1997. Explains the dbANYWHERE approach.

Glossary of Terms

Application Programming Interface, a coherent set of programmer-oriented definitions and calls for achieving a related set of objectives.

A quality of a data item to which a specific value may be associated. Attributes appear in relational databases as column headers and in object-oriented databases as variables in each object.

A graphical query interface for relational databases conceived and prototyped at HMC as part of the Grok project. The Condor prototype was implemented in XPCE (X-Window version of the Portable Computing Environment from SWI in the Netherlands) and Prolog.

A condition imposed on the selection of objects from a table in addition to join conditions.

An API created by Symantec that provides an implementation of JDBC and various utility features, such as the ability to access a variety of JDBC-compliant databases.

Graphical representation knowledge, a software tool for extracting information from textual articles and creating graphical objects representing entities in the article and connections between those objects. The current version of Ogre has no direct connection to Grok.

Graphical User Interface

Cause an attribute to be removed. The attribute cannot be joined to others. If it is, it must be unjoined first

A commercial relational database management system produced by Informix Corporation.

A Java-based API for accessing relational databases.

a relational database term, meaning to create a table from two or more tables by creating rows where the attributes have common values. Ogre provides for joining on operators <, >, IN, etc. as well as equality.

null values
relational databases allow the values of some attribute to be missing. These are called null and show up as blank in the tables. When Ogre creates objects, it suppresses the attributes corresponding to null values. Rows of a table are not joined if either joining attribute has a null value.

Cause an attribute's name to be removed while leaving the attribute. The attribute can still be joined to others, but the values of a masked attribute will not appear in the resulting object.

Objects Generated from Relations, the topic of this guide, is a software tool for creating an object-oriented database from a relational database.

object-oriented database, a database in which the primary unit of structuring is an object. In our case, each object consists of a set of attributes with corresponding values of the attributes.

Open Database Connection, an API defined by Microsoft for accessing databases using SQL. Network-based implementations of ODBC exist for a wide variety of relational databases.

A relation that is defined algorithmically, rather than being in a table. Examples of operators in Ogre are the arithmetic comparisons: <, >, <=, >=, <>, ==, LIKE, and NOT LIKE.
A commercial object-oriented database management system produced by Poet Software Corporation.

Another name for a table of data. The data items are identified with rows of the table. Each item specifies values of attributes, which are identified with the columns of the table.

relational database
A database in which the primary unit of structuring is the relation or table, in contrast to an ODB.

In this document, the schema for an object-oriented database may be regarded as the set of attributes for each type of object which will be created.

To reverse the effect of hide.

Structured Query Language, a standard language for accessing relational databases.

To undo the effect of mask.

Universal Resource Locator, the means by which Ogre refers to relational databases and object-oriented databases.

Summary of Mouse Actions

Clicking on canvas backgroundunselects all nodes
Clicking a nodeselects the node
Shift-clicking a nodetoggles the node into or out of the current selection
Dragging starting on the canvas backgroundselects all nodes circumscribed
Dragging a selected nodemoves all selected nodes
Control-clicking a relation nodepops up choices regarding the relation
(remove, select all attributes, show all attributes, hide all attributes, show schema)
Control-clicking an attribute nodepops up choices regarding the attribute
(rename, hide, mask, unmask)
Double-clicking an edgetoggles the original attribute name for that edge
Double-clicking a schema name in the schemas menuopens a window for that schema
Double-clicking an attribute or schema name in a schema windowrenames the attribute or schema

How to Achieve a Specific Effect

How to Achieve
Select a nodeClick on the node.
Select a grouping of nodesDrag the mouse across a diagonal of the region to be selected.
Unselect all nodesClick on the background.
Add/remove a node to/from selectionHold shift while clicking on node.
Select all relation nodesHold shift while clicking each node.
Select all nodesDrag the mouse across a diagonal of the canvas. .
Move nodesSelect the nodes to be moved, then drag any selected node.
Hide, mask, or unmask an attributeControl-click the attribute, then select appropriate action.
Show original attribute nameDouble-click the edge to which the attribute corresponds.
Show a schema definitionControl-click a node in the schema, then choose show schema, or double-click the schema name in the schemas list.
Rename an attributeControl-click the attribute, then choose rename, or show the schema and double-click the attribute.
Rename a schemaShow the schema and double-click the schema name.
Rename a relationYou can't, since relation names are fixed in the relational database. .
Show or generate objects directly from relationsCheck the RDB box, then select the relations of interest, then press either the Show as Table button or the Generate Objects button.
Show or generate objects from schemasCheck the Schemas box, then select the schemas of interest, then press either the Show as Table button or the Generate Objects button.
Show the SQL without showing tables or generating objectsSelect either the relations or the schemas as above, then press Show SQL. The SQL will be listed in the Log window.