 |
Description  |
|
|
The present invention relates generally to layout planning systems for
interface displays, and particularly to automatic methods and systems for
generating user interface layouts.
BACKGROUND OF THE INVENTION
As is well known, computer programs have become easier to use as a
consequence of the development of graphical user interfaces. The
proliferation in the number of applications programs with graphical user
interfaces is partly the result of the advent of windowed user
environments (e.g., Microsoft Windows). Unfortunately, the creation of a
graphical user interface generally requires the utilization of user
interface "toolkits" by highly-skilled programmers. While user interface
toolkits enable a programmer to specify the manner in which a particular
data structure is displayed, such toolkits do not address the task of
designing the entire interface. Instead, design of the overall interface
generally requires an application programmer to:
(1) become knowledgeable about the toolkit and its virtual devices, e.g.,
text fields, scrolled text windows, push buttons, pull-down menus and the
like.
(2) select appropriate virtual devices based on the input and output
requirements of the application,
(3) customize the devices for the particular application,
(4) lay out the selected devices on the interface display, and
(5) write code which initiates the interface and integrate it with the
application.
Although this creates an interface for an existing application, changing
the application typically requires corresponding changes to be made to the
interface. It follows that parallel development of an application and its
interface requires repeated and costly revisions. Hence, increased
interest has developed in the development of tools to automate the design
of graphical user interfaces.
In the field of database applications there exist several types of tools
used to facilitate the design of user interfaces. Among these are included
stand-alone form managers, fourth generation languages, graphical user
interface builders, automatic graphical user interface generation systems,
and automatic layout designers. -In addition, application specification
languages and visual tools based on what has become known as the
"EntityRelationship" model are also used in the development of user
interfaces.
Stand-Alone Form Managers
Commercially available stand-alone form managers (e.g., INGRES/QBF by Ask
Computer Systems Inc., INFORMIX/PERFORM by INFORMIX Software Inc., and
ORACLE/SQL*FORMS by ORACLE Corp.) enable the generation of complete
database applications with a minimum programming effort. Developers design
the layout of the application screens with a graphics editor, then link
the fields in the display with their database counterparts using an
interactive mechanism or a simple script language. This mode of
interaction grants the user access to the database through screen layouts
resembling business forms. Although form managers shorten development
through automatic generation of database calls, these were originally
intended to be used in devices with limited graphical capabilities (e.g.,
ASCII terminals). Hence, form managers are incapable of taking advantage
of graphical user environments; A further disadvantage of stand-alone form
generators is that the creation of sophisticated applications typically
requires the use of script languages, which are often unfamiliar to
inexperienced users. Moreover, stand-alone form generators require the
application developer to customize the interface for each application and
for each environment in which it is to run.
Fourth Generation Languages
Fourth generation languages combine the screen layout facilities of a form
manager with a programming language that supports database calls, controls
the interaction between the user and the application interface, and allows
general purpose computations. Fourth generation languages (e.g.,
INGRES/4GL by Ask Computer Systems Inc., and INFORMIX/4GL by INFORMIX
Software Inc.) remove some of the limitations exhibited by stand-alone
form managers by enabling applications developers to add specialized code.
An editor is still used to design the layout of the interface, but code
must be provided to control the flow of data between the interface
display, i.e., computer screen, and the database. Fourth generation
languages are advantageous in that a portion of the dialog control code is
generated automatically, and in that modification may be made to the
layout of the interface without rewriting code.
Like stand-alone form managers, fourth generation language systems lack
graphical interface capability except when combined with graphical user
interface builder routines. Moreover, fourth generation languages
generally require that more detailed programming be performed than with
stand-alone form managers.
Graphical User Interface (GUI) Builders
A series of user interface management systems (UIMS) and interactive design
tools (IDTs) have recently been developed. These development aids,
commonly referred to as graphical user interface (GUI) Builders, can be
used in conjunction with fourth generation languages to produce
application programs having relatively sophisticated user interfaces. GUI
Builders allow for more flexibility in interface design than do form
managers, since users may interact with the database in a manner not
dictated by the style of a typical business form.
GUI Builders generally include several visual design tools, including a
What-You-See-Is-What-You-Get (WYSIWYG) Editor, which enable:
(1) interactive selection and placement of the graphical objects (defined
by blocks of code known as "widgets") comprising the interface, and
(2) assignment of values to various attributes, e.g., size, color and font
type, of each graphical object. In addition, UIMS also allow for the
selection of callback functions, the attachment of user-defined code, and
the generation of code used to realize the interface screen display.
Unfortunately, the format of interfaces designed using GUI Builders
depends exclusively upon knowledge possessed by the application developer.
That is, information relating to desirable design practice is not embedded
within GUI Builders. It follows that the quality and consistency of
interface layouts produced using GUI Builders will vary considerably.
Intelligent GUI Generation Systems
Recent research has yielded several systems capable of automatically
generating application programs having graphical user interfaces. These
systems use high-level descriptions of the behavior and appearance of data
objects included within the application program to produce either an
executable program, or source code which is to be edited and refined by
the developer prior to generation of the program.
Since the intelligent GUI systems listed above have been developed for
general-purpose applications, such systems tend to be incapable of
utilizing information specific to particular applications. For example, in
database applications such information would include parameters stored
within a database dictionary. As a consequence, the code produced by
automatic GUI systems generally must be edited so as to be in conformance
with the requirements of specific applications. Alternatively, a detailed
specification of the database structure could be provided to the automatic
system.
Automatic Layout Generators
These systems employ heuristics and rule-based methodologies from expert
systems in order to determine an appropriate arrangement for the group of
objects represented in the interface. Automatic layout generators are used
to automate the portion of the interface design process associated with
positioning each interface object, but are generally not utilized in other
aspects of interface design. One example of this type of system is
disclosed in U.S. Pat. No. 4,700,317 entitled AUTOMATIC LAYOUT PLANNER AND
METHOD FOR AUTOMATICALLY CREATING A LAYOUT PLAN, issued Oct. 13, 1987.
Application Specification Languages
Application specification languages allow an application and its interface
to be represented using high-level descriptions. These languages enable
utilization of a higher level of abstraction than is possible using
standard programming languages, e.g., C or C++. This shortens programming
time, and tends to reduce the occurrence of errors arising when
application developers are forced to keep track of an excessive number of
details relating to the application. Unfortunately, however, existing
application specification languages have typically been tailored to
address the needs of general-purpose applications rather than to specific
applications such as, for example, those relating to databases.
Accordingly, existing application specification languages have been
incapable of efficiently utilizing the information available in the data
dictionaries of database applications.
Visual Tools Based on the Entity-Relationship (ER) Approach
ER diagrams are commonly used by application developers as visual tools for
modeling data. However, because of limitations in the graphical
capabilities of computers in existence at the time that data modeling
based on ER diagrams was conceived, it has only recently become possible
to fully realize the potential utility of ER diagrams. In this regard
numerous commercial data modelers and computer aided software engineering
tools based on the ER model or one of its many variations have recently
been developed. These systems can be used to create and manipulate
graphical representations of a database schema, in some instances
producing the textual descriptions needed to create or to modify the
database.
ER diagrams have also been utilized within the visual query language field,
where graphics are employed in the provision of user requests to the
system. Specifically, ER diagrams enable graphical description of the data
of interest, but enable results to be presented in only a fixed,
pre-determined form.
OBJECTS OF THE INVENTION
It is an object of the present invention to provide an interface layout
generator capable of producing interfaces, particularly interfaces for
database applications, in a manner requiring minimal user specification
and operation.
It is a further object of the present invention to integrate information
stored within a database dictionary with expert knowledge relating to user
interface design into predefined design criteria utilized during
generation of such interfaces.
SUMMARY OF THE INVENTION
In summary, the present invention is an automatic interface layout
generator for database systems operative to simplify the process of
creating graphical user interfaces by performing tasks (e.g., screen
layout design and virtual device selection) in the absence of human
intervention. The automatic generator includes a specification tool for
specifying a set of block descriptions representative of specified
portions of a database. A block layout generator produces interface
objects to be included within a database interface, wherein each of the
interface objects corresponds to one of the block descriptions and
includes a plurality of layout fields. A layout quality parameter is
determined for each of the interface objects based on arrangement of the
layout fields within the interface objects. A block placement generator
arranges sets of the interface objects into block configurations within
the interface. A placement quality parameter for each of the block
configurations is derived based on a set of block placement rules and on
the layout quality parameters, and a final block configuration is selected
by comparing the placement quality parameters corresponding to particular
block configurations.
In a preferred implementation the specification tool operates to identify a
set of objects of interest in an ER diagram. This specification operation
may be considered akin to defining a view of the database. In particular,
the specification tool transforms the objects of interest in the ER
diagram into statements descriptive of application components suitable for
immediate use by a screen generator.
BRIEF DESCRIPTION OF THE DRAWINGS
Additional objects and features of the invention will be more readily
apparent from the following detailed description and appended claims when
taken in conjunction with the drawings, in which:
FIG. 1A is a block diagram of a preferred embodiment of the inventive
automatic interface layout generator for database systems.
FIG. 1B is a more detailed representation of an interface specification
tool included within the automatic layout generator of FIG. 1A.
FIG. 2 depicts an example of a display of a database schema.
FIG. 3A depicts an application specification diagram produced by editing
the schema shown in FIG. 2 using a schema editor.
FIG. 3B depicts the screen layout of a typical database application.
FIG. 4A provides a generalized representation of a data structure within a
primary memory representative of the database schema of FIGS. 2 and 3.
FIG. 4B shows one example of a data structure in the form of an Operations
Table which may be employed to represent the status of the operations
panel.
FIG. 5 represents a database dictionary with which are associated the
entries within the Operations Table of FIG. 4B.
FIG. 6 depicts an interface in which multiple occurrences of the entities
ITEM and ORDER are shown simultaneously.
FIG. 7 represents an interface in which relationships between the multiple
displayed entities must be inferred by the user of the interface.
FIGS. 8A-8C illustratively represent pull-down menus associated with the
`File,` `Edit,` and `Schema` commands available to an interface designer
in an exemplary embodiment.
FIG. 9 depicts a graphics window used to prompt an interface designer for
the name of a database for which an interface is to be generated.
FIG. 10 illustratively represents a pull-down menu associated with the
`Interpret` command available to an interface designer in an exemplary
embodiment.
FIG. 11 shows a block diagrammatic representation of a particular
implementation of the display code generator and compiler operative to
process the final block placement file derived from the block description
files.
FIG. 12 depicts a screen display corresponding to a particular application
specification diagram (ASD).
FIG. 13 shows a block precedence tree (BPT) having nodes and branches
respectively corresponding to entities and relationships depicted within
the ASD of FIG. 12.
FIG. 14 shows an interface screen generated in accordance with the BPT of
FIG. 13 from which the entity "School" has been selected from a menu
screen displaying a plurality of entities.
FIG. 15 is a functional block diagram representative of a preferred manner
of generating an interface layout in accordance with the present
invention.
FIG. 16 is a block diagrammatic representation of the components comprising
a block layout generator included within the present invention.
FIG. 17A shows an example of a template which, together with a block
description file, are utilized by the block layout generator to produce a
set of three object blocks depicted in FIGS. 17B-17D.
FIG. 18A is a sliced tree representation of a set of object blocks included
within a block configuration shown in FIG. 18B.
FIG. 18C shows an initial block placement corresponding to the sliced tree
representation of the initial placement depicted in FIG. 18B.
FIG. 19A depicts an initial interface placement of object blocks
corresponding to each of N block description files.
FIG. 19B is a sliced tree data representation corresponding to the initial
interface placement of FIG. 19B.
FIGS. 20A and 20B depict changes occurring to a block configuration as a
consequence of execution of a Replace operation performed during a
simulated annealing block placement procedure.
FIGS. 21A and 21B depict the effects on a block configuration resulting
from a Swap operation.
FIGS. 22A and 22B depict the effects on a block configuration due to a Move
operation.
DESCRIPTION OF THE PREFERRED EMBODIMENT
Introduction
Referring to FIG. 1A, there is shown a block diagram of a preferred
embodiment of the inventive automatic interface layout generator 10 for
database systems. The automatic layout generator 10 of the present
invention includes a general purpose computer system 100 having a central
processing unit 102 that is interconnected by a system bus 104 to primary
memory 106 (i.e., high speed, random access memory), to secondary memory
107, and to one or more input units 108. Each input unit 108 typically
includes a keyboard 110, and a mouse pointer device 114 with item
selection button 116. Stored in primary memory 106 are an interface
generation program 120, as well as a display code generator and compiler
122. As is described hereinafter, the interface generation program 120 is
operative to automatically design a user interface for a database stored
in secondary memory 104 when appropriate instructions are received from a
user via input unit 108. In particular, a diagram representative of the
database resident in memory 104 is initially displayed on a display unit
128 using information included within the dictionary of the database and
standard graphic layout techniques. An interface specification software
tool 129 allows the user, i.e., the interface designer, to select portions
of the database structure of interest. This selection is accomplished
through a series of point and click operations using pointer device 114 in
which the user removes from the database diagram those entities, entity
attributes and entity relationships not intended to be represented within
the user interface. An interpreter module (not shown) creates a block
description file 130 for each entity and relationship included within the
database structure selected using the interface specification tool 129.
As employed hereinafter, the term "entity" refers to an object recognizable
by the user of an application program (e.g., an object, location or the
like) which is described by information stored within an application
database. An "attribute" refers to a particular characteristic of an
entity (e.g. color, shape, distance), and are represented in the database
by attribute values. This allows a specific "entity occurrence", or simply
"occurrence", to be defined by the set of information resulting from
selection of an attribute value for each attribute associated with the
entity. Finally, a "relationship" represents an association between two or
more entities.
Again referring to FIG. 1A, the interface generation program 120 includes a
block layout generator 134 for synthesizing a set of graphical object
blocks of varying geometry for each of the entities defined within the
block description files 130. A block placement routine 136 is used to
determine a preferred placement of object blocks within the user interface
in accordance with a combinatorial optimization routine. In this routine
the quality of the user interface resulting from various combinations of
object blocks is evaluated based on predefined criteria, wherein each
combination includes one object block corresponding to each block
description file 130. The block combination of highest quality is stored
within a final block placement file 140. Referring to FIG. 1, code
generator 122 then generates display code based on the user interface
design defined by the final block placement file 140. This code is stored
in display code memory 144, and is accessed by an interface display driver
146 during display of the user interface via display unit 128.
Detailed Description
As mentioned above, the interface specification tool 129 enables the
interface designer to specify which portions of a database stored in
secondary memory 104 are to be represented in the user interface created
by the interface generation program 120. An application is typically
characterized by specifying:
(1) a list of the entities, relationships and attributes of interest; and,
(2) a set of indicators describing the number of occurrences to be
displayed for each entity.
Referring to FIG. 1B, there is shown a more detailed representation of the
interface specification tool 129. The interface specification tool 129 is
an interactive mechanism which provides an interpreter module with the
information necessary to synthesize the block description files 130. This
is done through a series of operators that enable the systematic
transformation of a schematic representation of a semantic database schema
diagram (SSD) into a second type of representation, termed an application
specification diagram (ASD), defining the entities and relationships of
interest.
The following description of the interface specification tool 129 is
intended to describe one manner in which a database structure for which an
interface is to be generated may be specified. At the conclusion of this
database specification process the block description files 130 are created
by the interpreter. It is understood, however, that such block description
files may be created by the direct entry of information relating to the
structure of the portion of a database for which an interface is to be
designed.
In a preferred implementation the interface specification tool 129 is coded
in a standard programming language (e.g., C or C++) and includes the
following components: (i) a database schema (SSD) generator 150, (ii) a
schema editor 152, and (iii) an application specification diagram (ASD)
interpreter 154.
As noted above, one way in which a given database schema (SSD) may be
graphically represented is in terms of an ER diagram. FIG. 2 depicts one
manner in which an SSD representative of a database relating to the
organization of a company could be displayed via an ER diagram. The SSD
generator 150 extracts information about the structure of the database
from the database dictionary and converts it into an ER diagram. The SSD
generator 150 includes an SSD layout generator 156 which determines the
position of each entity, relationship and attribute in the ER diagram. The
ER diagram of FIG. 2 allows the interface designer to select objects
representative of entities of interest (e.g., EMPLOYEES, DEPARTMENTS,
ITEMS, SUPPLIERS, ORDERS and CUSTOMERS).
The schema editor 152 is used by application developers to transform an SSD
of the database, as represented by an ER diagram, into an application
specification diagram (ASD) such as is shown in FIG. 3A. In effecting this
transformation four operations are performed by the schema editor: (1)
specification of occurrence indicators, (2) diagram trimming, (3) diagram
labeling, and (4) definition of master-slave relationships. With regard to
operation (1), entities may be further categorized as either
single-occurrence (S) or multiple-occurrence (M) entities. When defined in
a given ASD as a single-occurrence entity, a single occurrence of the
entity would appear in the interface generated on the basis of the given
ASD. Similarly, multiple occurrences of entities specified within an ASD
as being of the multiple-occurrence type would be made to appear within
interfaces derived from the particular ASD. As is described hereinafter,
the present invention provides a method for generating a graphical user
interface (GUI) exemplified by, for example, the screen layout of FIG. 3B,
on the basis of an ASD such as depicted in FIG. 3A.
FIG. 4A provides a generalized representation of a data structure within
primary memory 106 representative of the database schema of FIGS. 2 and
3A. As shown in FIG. 4A, information pertaining to a plurality of
entities, i.e., Entity.sub.-- 1, Entity.sub.-- 2, . . . , Entity.sub.-- m,
is stored in an Entity List. Specifically, stored within a data field F1
corresponding to Entity.sub.-- 1 are the following values: (1) a string
(Label) indicative of the name of the entity; (2) a pair of integers
(Position) specifying the (x,y) coordinates in the display where the
entity is to be shown; and (3) three indicator values (Al, M, O) used by
the schema editor 152 and interpreter 154 to keep track of the entity
status during the specification process. Also included in field F1 is
numerical pointer P11 corresponding to the memory location of the field
associated with the first attribute, i.e., Attribute.sub.-- 11, of
Entity.sub.-- 1. Similarly, the value of numerical pointer P12 indicates
the location of data field F2 associated with Entity.sub.-- 2. A null
pointer NP indicates the end of the Entity List.
An Attribute List includes sets of data fields corresponding to the
attributes of each entity within the Entity List. For example, if
Entity.sub.-- 1 corresponds to the DEPARTMENT entity within the database
schema of FIG. 2, then Attribute.sub.-- 11 would refer to Id,
Attribute.sub.-- 12 to Name, and so on. Each entry in the attribute list
possesses values for the text associated with the attribute name (Label)
and its position in the display (Position). A single indicator value (Al)
is used by the schema editor 152 and interpreter 154 to keep track of the
attribute status during the specification process. The value of the
pointer PA 11 included within the field of Attribute.sub.-- 11 is
indicative of the memory location of Attribute.sub.-- 12. As shown in FIG.
4A, a Relationship List includes a plurality of linked data fields
defining the relationship between entities displayed via the schema
editor. As in the case of entities, each relationship may have associated
therewith a set of attributes defined within a Relationship Attribute
List. If the database schema of FIG. 2 is used as an example, the data
field Relationship.sub.-- 1 could be used to define the "supply"
relationship between ITEMS and SUPPLIER. The Label, Position and Al values
within Relationship.sub.-- 1 specify the position and status of the
"supply" text within FIG. 2, while the Cardinality value of M:N indicates
the ratio of the number entries within ITEMS and SUPPLIERS.
The schema editor facilitates selection of the entity relationships
depicted in FIG. 3A by modifying the entries within the data structure of
FIG. 4A on the basis of information provided by the interface designer.
For example, assume that in FIG. 2 that the entity EMPLOYEES corresponds
to Entity.sub.-- 2 (FIG. 4A). Upon deletion of the Birthdate attribute
associated with EMPLOYEES (FIG. 2) using a point and click operation, the
schema editor would change the value of the pointer PA21 of
Attribute.sub.-- 21 so as to reflect the memory location of
Attribute.sub.-- 23.
The interface specification tool 129 will also preferably include an
operations panel in which graphical icons in the form of "buttons" or the
like representative of common database operations are made available to
the interface designer during the database specification process. Included
among these common operations are RETRIEVE, UPDATE, INSERT, DELETE,
PREVIOUS, NEXT, and EXIT. The icons representative of these operations can
be toggled by the interface designer using a series of point and click
operations in order to select/de-select particular operations. FIG. 4B
shows one example of a data structure in the form of an Operations Table
which may be employed to represent the status of the operations panel. The
specification tool 129 considers all operations to be selected by default,
and imposes the following constraints upon the chosen set of operations:
(1) EXIT cannot be de-selected,
(2) if DELETE is selected, then RETRIEVE must also be selected, and
(3) if UPDATE is selected, then RETRIEVE must also be selected.
As is described hereinafter, the application specification tool and the
layout generator of the invention utilize information stored within the
dictionary of a selected database used to create the block description
files (BDFs) 130. The manner in which the BDFs are synthesized may be more
readily explained by making reference to the structure of such a database
dictionary. Accordingly, FIG. 5 illustratively represents the structure of
a typical database dictionary. An explanation of each of the records
included within the dictionary of FIG. 5 is set forth below:
Directory
One record is created for each directory.
______________________________________
Id Directory number
Name Directory name
Parent Parent directory number
Area Default value for the area number of the
UNIX directory under which files related to
the database are created.
Primary key
(Id)
Secondary key
(Parent, Name)
______________________________________
Database
One record is created for each database.
______________________________________
Id Database number
Name Database name
Parent Parent directory number
Note Comments
Area Default value for area in which files related
to this database are created.
Primary key
(Id)
Secondary key
(Parent, Name)
______________________________________
Record
One record is created for each record type.
______________________________________
Id Record type number
Name Record type name
Parent Database number
Note Comments
File Record file number
Heap Heap file number
Key Array of field numbers comprising primary
key
Primary key
(Id)
Secondary key
(Parent, Name)
______________________________________
Field
One record is created for each field.
______________________________________
Id Field number
Name Field name
Parent Record type number
Note Comments
Order The logical field number within the record
Type Encoded data type
Dim Number of elements in array
Offset Field position within record
Init Test representation of initial value
Integ Integrity information
NullOk Allows or disallows null values.
Primary key
(Id)
Secondary keys
(Parent, Name)
(Parent, Offset)
______________________________________
Index
One record is created for each index.
______________________________________
Id Index number
Parent Record type number
Note Comments
File Index file number
Key Array of field numbers comprising keys
Unique Allows or disallows duplicates.
Primary key (Id)
Secondary keys
(Parent)
(Key)
______________________________________
RLink
One record is created for each real-link type.
______________________________________
Id Real-link type number
Name Link name (null value for unnamed inverse
link types)
Parent Database number
Note Comments
File Real-link file number
Inverse Inverse link type number
Term Terminal record type number
Integ Integrity information
Primary key
(Id)
Secondary keys
(Parent, Name)
(Term)
(Inverse)
______________________________________
VLink
One record is created for each virtual-link type.
______________________________________
Id Virtual-link type number
Name Link name (null value for unnamed inverse
link types)
Parent Database number
Note Comments
Inverse Inverse link type number
Term Terminal record type number
Termkey Array of field numbers comprising key of
terminal table
Integ Integrity information
Primary key
(Id)
Secondary keys
(Parent, Name)
(Term)
(Inverse)
______________________________________
Area
One record is created for each area in which files are created.
______________________________________
Id Area number
Name Absolute pathname within UNIX filesystem
Primary key
(Id)
Secondary key
(Name)
______________________________________
File
One record is created for each file.
______________________________________
Id File number
Name Logical name of file (does not match UNIX
file name)
Parent ID number of the area in which file is stored
Object ID number of the record type, index or real-
link type this file defines
Db Database number
Type Classification as sequential file or B-tree,
and as fixed length or variable length
FkSize Number of bytes in fixed-length key section
VkSize Number of bytes in variable-length key
section
FvSize Number of bytes in fixed-length data section
VvSize Number of bytes in variable-length data
section
Primary key
(Id)
Secondary keys
(Parent)
(Db)
______________________________________
User
One record is created for each user.
______________________________________
Id User number
Name User name
Type Classification as UNIX user, UNIX group
member or as user administered solely by
GraphBase using password
Osid UNIX user number of group number
Passwd Encoded password
Primary key
(Id)
Secondary keys
(Type, Name)
(Type, Osid)
______________________________________
Access Permissions
One record is created for each permission granted.
______________________________________
User User number
Object Access object number
Type Type of access indicated using bit pattern
Primary key
(User, Object)
Secondary key
(Object, User)
______________________________________
Statistics
One record is created for each access object.
______________________________________
Object Access object number
Ctime Date and time that data definition was first
made for access object.
Mtime Date and time that data definition was last
made for access object.
Account Array containing number of times
processing was carried out for each access
type.
Primary key
(Object)
______________________________________
The database dictionary of FIG. 5 includes the following virtual links
between the indicated records to facilitate queries made by the
interpreter module during generation of the block description files 130:
DirectoryDirectory Sub-directories belonging to directory
DirectoryDatabase Sub-databases belonging to directory
DatabaseRecord Record types belonging to database
RecordField Record fields belonging to record type
RecordIndex Indexes belonging to record type
DatabaseRLink Real link types belonging to database
DatabaseVLink Virtual link types belonging to database
RecordRLink Real links connected to record type
RecordVLink Virtual links connected to record type
RLinkRLink Inverse link type corresponding to real-link type
VLinkVLink Inverse link type corresponding to virtual-link type
RecordFile Re | | |
