Interface

BG-BASE presents a consistent interface throughout its many modules and features. It is mouse or keyboard driven, has pull-down menus and popup selection boxes and allows the user to suspend one operation to do another (depending upon available memory on your computer). Extensive editing and pattern-matching is done automatically by the system, much of it controlled through a series of user-defined records in the CONFIGURATION table. Context-sensitive help – over 6,000 screens' worth – is available in virtually all parts of the system; this help can be translated into languages other than English if desired.

Data entry is done through entry forms, which provide context-sensitive help for each field and which perform many data checks and validation procedures, as well as maintaining the many indexes used by the system. Standard reports are readily available via the mouse or with simple keystrokes.

BG-BASE manipulates images through its IMAGES table. It can be linked with both GIS and CAD systems, and drives a wide variety of printing, engraving, embossing and barcode devices (see the outputs document); it can also be used with various hand-held data input devices.

Menus
BG-BASE employs an extensive range of menus to aid the user through the tasks of entering, editing, and querying data.

Popups
Popups provide pick lists from which to choose one or more options. Popups are used extensively in entry windows especially when a field can only accept certain values. These popups may present static lists from which to choose (as with coded fields) or they may dynamically change to display information in other parts of the system (as in the popup that displays whenever you look up a record via an indexed field - the system displays a popup of those records that match the selection criteria).

Many Popups allow multiple selections, which allows you to create browse lists for entry windows 'on the fly'.

Click here to see a popup from the ACCEPT field in NAMES.

Entry forms
Entry forms are essential elements of using BG-BASE. Virtually all data entry and editing is done via entry forms, and much querying of the database can also be done through them (although in most cases, queries are best done through OpenInsight's native query language or through one of BG-BASE's query tools). Each database table has one or more entry forms specific to that table. Context-sensitive help is available at each field in the entry form.

The key field (green background) is shown first on each entry form, but this same field also allows you to query the database for the appropriate record(s) by using one or more indexes. Virtually all database tables are indexed on a special field, ETI (Everything To Index), and it is this ETI index that is used automatically by the system when you enter a search term at the key field prompt. (Thus, if you were trying to find the record for Acer rubrum in the NAMES entry window, you could simply enter acer rubrum at the key field prompt.)

By using this ETI field, which values from several fields and indexes them together, you do not have to know which field has been used to hold the data you are interested in; this is especially useful when looking up data sources (the system will return all matches for one or more words, no matter if those words appear in the author's last name, the title or subtitle of the reference, the name of the journal, or in keywords) and when looking up scientific names (the system will return all matches for one or more words, no matter if those words appear in any part of the scientific name, any synonyms attached to a particular name, in the common names attached to a scientific name, or in the keyword field, which can be used to hold any common misspellings). If you do not know the correct spelling of a word, you can perform partial-word searches.

Some database tables, such as NAMES, have a particularly large number of fields; in these cases, the entry form may be composed of several pages.

Fields in entry forms may be either optional or required; the record cannot be saved until all required fields are filled in. In addition to the "standard" fields in an entry form, most BG-BASE tables also have 5-10 user-defined fields. These user-defined field can be used in any way that suits an institution's specific needs, and institution-specific context-sensitive help can be created for these fields.

When appropriate, BG-BASE determines the correct capitalization / decapitalization for the values entered; this means that you can enter all information as lowercase letters and the system will uppercase only those letter that are appropriate. The subroutine controlling this feature is turned off once a field has information in it, so you can make any changes necessary by editing existing data in a field. There is a record in the CONFIGURATION table that stores a user-defined list of acronyms and other words that should follow unusual capitalization rules.

All records are stamped with the current user's initials (as determined by the BG-BASE logon process) and the current date; this takes place when a record is created or edited (but not when it is simply viewed in the form). One of the help options on the menu bar above every entry form can display a popup of users and dates for all edits of that record.

A subset of a table's records may be selected based on any selection criteria and then the selected records can be brought into the appropriate entry form as a browse list. This is especially useful for checking or editing large numbers of records.

Click here to see a popup from a NAMES search on everything starting with GUN.

Help
Extensive help is available throughout the system. Every field in every entry form has context-sensitive help associated with it. These help screens explain the rationale of the field, what validation checks are placed on it, how the field relates to other fields, and so on. Because of the large number of fields in BG-BASE, no attempt is made to make all field-specific help available in printed form, since this would require more than 1,000 pages to print. There is also help on common procedures available in the FAQ (Frequently Asked Questions) table.

If desired, this context-sensitive help can be translated into languages other than English.


Use on a network
BG-BASE has been designed from its outset to be run on Local Area Networks (LANs), Wide Area Networks (WANs) as well as on stand-alone systems. On a network, the system automatically performs record locking, thereby preventing two people from trying to update the same record at the same time. Other users can view a record that is being edited by someone else, but they cannot make any changes to it until the original user unlocks the record by removing it from the entry form. (Running BG-BASE on a network requires additional software; see the system requirements document.)

Security
Database security is handled by a combination of features within and external to BG-BASE:

* in a networked environment, general system security is handled by the network operating system (potential users are not given access to BG-BASE until there is a record in the USERS and STAFF tables for them; in addition, they need to be granted proper network access)
* in stand-alone installations, user rights and security information are handled directly by BG-BASE.

Users may be granted read/write privileges or read-only privileges. Individual users, even if they have read/write privileges, can be prevented from viewing or updating certain tables. All records are automatically updated with the current date and the initials of the user making the changes whenever they are created or edited.

Deleted records
Records deleted through entry forms are stored in a DELETED_RECORDS table, along with information on who deleted the record and when the deletion occurred. These deleted records can be restored, if necessary, by the system administrator.

Indexes
Indexes are essential to speedy data retrieval and to efficiently perform data entry. BG-BASE employs two types of indexes - BTREE and RELATIONAL. Most major tables have several indexes applied to them. In the case of an index corruption, the system provides tools to rebuild these indexes. (Index corruptions are rare occurrences; when they do occur, they are usually caused by faulty hardware, unstable electrical supply, by not using the correct network driver, or by not using the correct network performance product; see the system requirements document for further information.)

BTREE indexes and the ETI field
BTREE indexes index every word in a specified field and store these indexes as part of an index table associated with each database table (for example, the NAMES table has a !NAMES table associated with it that controls all NAMES indexing). Words are stored alphabetically. BTREE indexes support both full word searches and partial word searches ("beginning", "containing", "ending").

All major database tables have a special BTREEd field called ETI (Everything To Index) which is used automatically at the key field prompt of the entry form. This multivalue field "knows" all the relevant words for a record, allowing the user to search for all records matching any combination of words or partial words directly from the key field prompt. For example, if you wanted to look for all taxa that contain the word "alba" in any part of the scientific or common name, you would simply enter alba at the key field prompt.

If you wished to see only those "alba" records that were in the genus Rosa, you could enter rosa alba (or alba rosa - word order is unimportant).

If you wished to see all those records that begin with the letters "Sino" you would enter sino]; to see those ending in "phylla", you would enter [phylla; or to see those containing the letters "schw", you would enter [schw]. These partial word searches can be combined with one another and with full word searches. Multiple words or partial words are combined with a logical AND when searching at the key field of an entry form, and thus all returned records must meet all of the selection criteria.

In most major database tables, each word in the ETI field is also indexed using a phonetic lookup algorithm. This widely used algorithm has been modified in BG-BASE to better handle a combination of English, Latin, French, German, and Spanish phonemes. If an index search does not return any results using the spelling supplied by the user, the system asks whether it should perform a phonetic search on those same words (or partial words).

RELATIONAL indexes
Unlike BTREE indexes (which write to an index table), RELATIONAL indexes write information from a record in one database table to another record in a second database table. For example, the PLANTS table writes to a multivalue field in the ACCESSIONS table; this multivalue field then contains an instantly available list of all plants belonging to that accession. Another example of relational index is the LOAN_ITEMS table writing to the SPECIMENS table so that each SPECIMENS record "knows" if it is currently on loan, and when and to whom it has been loaned in the past.

Reports and the S/LIST Report Builder
BG-BASE produces a great many different kinds of reports. The primary reporting tool, S/LIST Report Builder, offers a sophisticated report wizard and library for saving and re-using existing reports and queries.

Here is screenshot a default S/LIST report for the PLANTS table and here is a print preview of the report

............................................................................................................................................................................................................................................

Special query tools
BG-BASE provides several special-purpose query tools, designed to simplify and speed up queries typically asked by BG-BASE users. These include FIND and INVENTORY.

FIND provides an extremely simple and fast method of finding the location, health, wild collection details for any accession in the collection; when used against a scientific or common name, it provides a collection summary report listing synonymy, living and dead accessions, herbarium specimens, propagations, germplasm, images and relevant bibliography; up to nine user-defined output formats can be stored and used in the FIND command

INVENTORY produces listings of all plants in a garden bed (or group of garden beds queried together); selections can be for only living plants or all plants ever in a location; sorting can be done by family scientific name, accession number, grid location within the bed, or inventory sequence number; inventories sent to the printer can be double-spaced in order to provide room for notes during stock-taking exercises; up to nine user-defined output formats can be stored and used in the INVENTORY command

COUNT TAXA produces a statistical chart for any subset of records in the collection of for the entire collection itself

............................................................................................................................................................................................................................................

Publishing from BG-BASE

BG-BASE has been used to produce several direct-to-page publications, producing camera-ready copy for the Arnold Arboretum's Inventory of Plants, the Holden Arboretum's Catalogue of Woody Plants, the Royal Botanic Garden Edinburgh's Catalogue of Plants, University of Oxford's A catalogue of the plants growing in the University of Oxford Botanic Garden and Harcourt Arboretum and the 1997 IUCN Red List of Threatened Plants compiled and produced by the World Conservation Monitoring Centre, among many others.

BG-BASE also produces RTF (Rich Text Format) output from various tables; this output can be used as input to virtually any word processor or desktop publishing system. The RTF output option has been used to produce two taxonomic publications from the Royal Botanic Garden Edinburgh (Accepted names in Rhododendron Section Vireya and The genus Rhododendron. Its classification and synonymy) as well as The RHS Plant Finder and Flora Conservanda. See the outputs document for further information.

There is also an HTML export module written by Martin Pullan of the Royal Botanic Garden Edinburgh for exporting OpenInsight databases such as BG-BASE into fully indexed HTML pages for use on the Web. See the outputs document for further information.

Top of Page