FAQs
Why does BG-BASE run on OpenInsight instead of something more "typical" like Access, dBASE, FoxPro, or Paradox?
OpenInsight (OI) used for BG-BASE is considerably more powerful and flexible than any of the more commonly used systems. No other relational database management system readily available for the PC market has the combination of variable-length fields and multivalue fields; these are traits that set OI apart from any of its competition, and they are traits that we rely on in the design and implementation of BG-BASE.
There is virtually nothing that these other more "typical" systems can do that OI cannot accomplish, often much more efficiently, and we have always sought the most powerful and flexible tool to handle the complex database needs of our users; properly managed, accessible information is vital to the well-being of any institution, and powerful, flexible, and proven software is required to do this. You will not hear much about AREV and OI in the popular press since; unlike Access, dBASE, Paradox, or FoxPro, it is not aimed at the mass consumer market. However, institution-wide, long-term databases containing data sets that grow to more than ca 50,000 records, such as those supported by BG-BASE, require something considerably more powerful than those lower-end systems.
Another important reason why we chose OI for BG-BASE as our database platform is that all OI applications run equally well as stand-alone (single computer) or as network systems. This means that we can develop a single version of BG-BASE that will work for both small and large institutions, and that sites can move from a non-networked environment to a networked environment when their needs grow (one or more Server Deployment Packs (SDP) packs is required when moving to a network; see the system requirements document). OI automatically handles the record and file locking that is critical to ensure data integrity on a network. Many of the lower-end products are designed primarily as single-user systems and some cannot even be run on a network at all, or if they can, then considerable effort must be expended to change from a stand-alone to a networked version - not so with OI.
What is the difference between BG-BASE and OpenInsight?
BG-BASE is a database application - a series of database tables, entry windows, reports, and programs - designed to manage collection information. It uses a commercially available database management system (DBMS) as its underlying platform; this DBMS is OpenInsight (OI) marketed by Revelation Software.
What is the difference between Advanced Revelation and OpenInsight?
Both Advanced Revelation and OpenInsight are high-end database management systems produced by Revelation Software. Advanced Revelation runs under DOS, and OpenInsight runs under Windows. They both permit variable-length fields and multivalue fields and employ the same linear hash architecture; thus data in one system is compatible with the other system. Think of OpenInsight as the next generation of Advanced Revelation, backward-compatible, but with lots of new features and a completely Windows interface. All further development in BG-BASE is taking place on the OpenInsight platform.
What is the difference between BG-BASE and BG-Map?
BG-Map, written by Glicksman Associates, is designed specifically to be used with BG-BASE for mapping purposes. It is the most widely used application of its kind, and we continue to work closely to insure compatibility between the two systems. All inquiries about BG-Map should be addressed to Mark Glicksman at BG-Map.
What is a "variable-length field"?
Database records are broken into fields (for instance, in BG-BASE's DS (data source) table, a record is composed of a field for the author's last name, another for the first name of the author, another for the title, another for the publisher, another for the abstract, etc. Most database management systems employ a fixed-length field architecture in which the designer of the database must declare what the maximum length of each field is; if the data entered for a particular record is shorter than the defined length, then the field is padded out with blanks, and if the data value is longer than the defined length, then it is truncated (unless the designer reformats the entire table, making the field longer, in which case all records will be padded out even further).
In contrast to this fixed-length architecture, BG-BASE employs a variable-length architecture in which most fields vary from 0 to 65,535 characters in length. That means that some records are long while others are short; each occupies only as much space as is necessary to store the data in it.
The advantages of this architecture are twofold: 1) space is not wasted by padding out fields to a predetermined length (this alone results in a 30-70% reduction in the size of a data set when moved from a fixed-length environment into BG-BASE); and 2) there is never a need to truncate a long piece of information (for instance, the title of a scientific paper, an abstract, etc.). (As an example, a 56,527-record database table provided by the World Conservation Monitoring Centre of Protected Areas handled in a fixed-length dBASE format required 12,662,402 bytes of storage; the same data when converted to BG-BASE's variable-length format, occupied 8,680,448 bytes (69% of the fixed-length size; the shortest record in this database was 34 bytes and the longest was 156 bytes, with an average of 80 bytes per record; greater space savings would be seen if there was a greater discrepancy between the longest and shortest record.)
Variable-length field technology is central to the way BG-BASE has been designed over the past several years. Without it, it would be virtually impossible to have developed the breadth and depth of BG-BASE as it currently stands, since each site would be wasting vast amounts of space for those features that they were not currently using; using variable-length technology as we do, all sites can share the same data dictionary, and thus all sites remain compatible with one another.
Why don't other systems use variable-length fields?
Good question! Variable-length database management systems are more difficult to design (although there is no difference as far as the user is concerned) since the filing system used by the database must be able to cope with records growing and shrinking in size as they are edited (in a fixed-length field architecture, all records are the same length and therefore can occupy a fixed position in the filing system no matter how much data has been entered in them, while in a variable-length field database, the records expand and contract as necessary and are automatically moved around in the filing system in order to maximize space efficiency). OI handle this via a powerful "hashing" algorithm and continually optimizes the way data are stored in its linear hash filing system.
Variable-length architecture has been well known in the mainframe and minicomputer markets for many years; why so few systems for microcomputers support variable-length architecture is a difficult question to answer. Some systems such as dBASE, FoxPro, etc., allow you to store a "memo" field, which is a rather crude, partial implementation of variable-length field architecture. However, these memo fields are not actually part of the record; instead, there is an internal pointer that links two parts of the filing system together. OpenInsight, on the other hand, manipulate all fields in a seamless, tightly integrated, variable-length architecture.
There is absolutely nothing that a fixed-length system can do that a variable-length system cannot do.
What is a "multivalue field"?
A multivalue field is simply a field that has been defined to hold one or more "values"; it can be thought of as a "repeating field". Most fields in BG-BASE are defined as single-value fields however, appropriate fields have been defined as multivalue fields. Examples of multivalue fields include the author field in the data sources table (allowing you to track up to multiple authors per data source), the common name field in the NAMES table, or the address lines in the CONTACTS table. Other systems that do not support multivalue fields would need to have a field called AUTHOR1, AUTHOR2, AUTHOR3, etc. It also means that if there was a fourth author for a particular data source, that information could not be tracked except by redesigning the database structure and adding a field called AUTHOR4. A further problem would be that if you searched for an author named "Smith", you would need to search individually in each of the AUTHOR, AUTHOR2, AUTHOR3 fields.
In multivalue fields in BG-BASE you can simply enter as many values as you require; there is no wasted space and there is no meaningful limit to how many authors can be tracked. In searching the database, each value is treated intelligently by the system. This means that you could say SELECT DS WITH LNAME = "SMITH" and would get all records whose author's last name is Smith, no matter if he/she was the first author, the second author, or the tenth author.
What is "linear hash" architecture?
The linear hash architecture employed by OpenInsight is a method of storing and retrieving data in an extremely flexible manner; it is proprietary to Revelation Technologies. It is especially efficient in storing textual information of inherently varying length. It employs a hashed key-based access method of storing data, meaning that the key field in any particular record is sent through a "hashing algorithm", which determines which "group" that record belongs in (all database tables in OpenInsight are subdivided into "groups" or "frames" automatically by the system). This provides very rapid access to the record and reduces the total number of data access incidents required, when compared to other, more typical, access methods. All this is invisible to the user, except for the consistently fast speed of access.
Retrieval time in a "typical" indexed database degrades directly in proportion to the size of the database (x * ln(x)); this makes large database tables, as are often maintained in BG-BASE, very inefficient in these other systems. However, with linear hash technology, access time remains fast, no matter if there are 10 records or a million records in a table. Also, only record is locked, unlike other systems that often lock the entire table when one record is held by a user.
The following table outlines the major features and benefits of linear hash architecture (although some of this may sound complicated, remember that all of this is invisible to the user):
Feature
Benefit
hashed keys are used to provide access, by key value, to a single record provides rapid access to records and reduces the total number of data accesses required compared to other access methods records are delimited string made up of variable-length fields provides economical storage of character string data tables expand and contract in small units maintenance is distributed across the network to multiple workstations, each doing a small amount of work when updating, locks are only applied to the group affected allows the remainder of the table to be accessed by other users or processes with minimal disruption
What is the table structure of BG-BASE?
BG-BASE is composed of nearly 170 database tables. Each table can contain an unlimited number of records, each of which is split into fields whose definitions are contained in the table's data dictionary. Each record has a key field, the one field (usually numeric and often provided by the system as a default) that uniquely identifies that record in the table. In addition to fields that actually store data, the data dictionary also stores definitions for " symbolic fields". These symbolic fields allow you to perform database joins and display or calculate information that may be stored in another table (or, indeed, in several other tables). There are a great many symbolic fields defined throughout BG-BASE, giving the user a particularly rich environment in which to manipulate data.
Because of BG-BASE's size, it is impossible to show the complete table structure in this document. However, see the tables document for general information about each of the tables, along with a diagram showing that table's interactions with other tables.
Why does BG-BASE have so many fields? Isn't this over-the-top, or wasteful of space?
BG-BASE fields are defined so that each field does one and only one thing. For instance, instead of storing the scientific name of a plant or animal as one string (e.g., "Rhododendron viscosum (L.) Torr. var. tomentosum Rehder"), BG-BASE has a field for genus, a field for species, a field for species author, a field for infraspecific rank, etc. (in fact, in order to meet the rules set out in the botanical, horticultural and zoological codes of nomenclature, nearly 30 fields are required to correctly handle scientific names, including those of hybrids. This gives you much greater specificity when querying the database.
Information that you enter into BG-BASE is stored in data fields, but there are also many symbolic fields that combine or manipulate these data fields (in some other systems, these symbolic fields are called "calculated fields"); for instance, there is a symbolic field called NAME in the NAMES table that combines the ca. 30 fields that make up a scientific name, and you can use this NAME field in any way that you would one of its constituent parts. It is the combination of these atomized data fields and the symbolic fields that adds up to the large number of fields making up BG-BASE as a whole.
Because BG-BASE is built on a variable-length field architecture each field uses only as much space as required by the data that have been entered into it for that record. This means, therefore, that you are not "wasting" space for fields in which you are not storing any data.
The overall goal in BG-BASE is to model real-life data as closely as possible; this means quite simply that there are a lot of fields in BG-BASE, but not any more than are necessary to do the wide range of tasks that it performs.
Does BG-BASE use a data dictionary?
Yes. Each database table has an associated data dictionary table that contains various parameters (field position, input conversions, output conversions, edit patterns, display length, justification (left, right, centered, or text-wrapped), default help, etc.) for each field (both data fields and symbolic fields) in that table. It acts as a series of "views" of the data in the table. The data dictionaries have been designed by BG-BASE, Inc., and in order to remain compatible with other BG-BASE users, you must not modify them. See, however, user-defined fields.
Can I make changes to a BG-BASE dictionary?
No. In order for all BG-BASE users around the world to remain 100% compatible with one another, we keep a centralized data dictionary. This master data dictionary comprises some 19,000 fields (both data fields and symbolic fields) in nearly 170 database tables. This rich data dictionary has been built up over several years based on user input, and it continues to grow regularly; controlling it centrally through BG-BASE, Inc. is the only way that it can remain synchronized for all users.
However, each of the major BG-BASE database tables has between five and ten user-defined fields. These fields are open to each institution to use as it sees fit. Using these UDFs permits users to handle institution-specific issues while at the same time retaining compatibility with all other users.
What is a BG-BASE "module"?
BG-BASE is a large system that handles a great many different kinds of data. In order to make its many features available at a reasonable price as well as to target specific audiences, it is broken up into modules, which can be purchased separately or in various combinations. These are explained more fully in the modules document.
Can BG-BASE manage DELTA-formatted data?
Yes. The DELTA module of BG-BASE allows you to define your own characters along with their type (unordered multistate, ordered multistate, integer numeric, real numeric, text, database) character states, dependencies, and specific help screens. Once the characters and their states are defined, you can then create as many DELITEMS (DELTA items) records as you wish. Each DELITEMS record prompts you for all characters, skipping those which are inappropriate based on character dependencies. You can add to and modify the DELCHARS table whenever you need to, and all existing DELCHARS records are automatically updated to reflect these changes.
BG-BASE produces the various output files as specified in the DELTA User's Guide.
What kinds of labels does BG-BASE produce?
Labeling is an essential part of managing any collection, and since BG-BASE handles so many different types of collections, it also produces a wide range of labels. These include: barcode labels, embossed labels, engraved labels, herbarium specimen labels, mailing labels, metal photo labels, plastic pot labels, and shipping labels, among others. See the outputs document for further information.
Can I use barcodes with BG-BASE and if so, what kind of barcodes should I use?
Yes, barcodes can easily be used in the DS, IMAGES, PLANTS, and SPECIMENS tables. You can either print your barcodes yourself (as is usually done for barcoded pot labels) or order pre-printed barcodes (as is often done for herbarium specimens or slides).
When purchasing a barcode reader, we strongly recommend a "plug and play" device that can be inserted between the keyboard and the computer; this will allow you to move the barcode reader to various machines without having to reconfigure the machine each time you move the reader. We also recommend that you use a "gun" reader rather than a "wand" reader, as gun readers tend to give a better, more accurate and faster scan.
There are many kinds of barcode encoding system available, including those that can only handle numbers and those that can handle both numbers and letters. Since barcodes are turned into text (letters and numbers) when read into BG-BASE, BG-BASE does not "care" what kind of encoding is being used. However, for space efficiency on pot labels, you would be well advised to consider Code 128. Many herbaria around the world have standardized on Code 3 of 9 encoding for barcoding specimens. For maximum space efficiency, you might consider using two-dimensional encoding.
Code 128 encoding (peel-off barcodes produced from BG-BASE) 
Code 3 of 9 encoding (peel-off barcodes produced from BG-BASE) Code PDF417 (2-dimensional) encoding (peel-off barcodes produced from BG-BASE) 
Code 128 encoding (peel-off barcodes printed from BG-BASE, ready to be stuck to plastic pot labels) (click image to see explanation of this kind of barcode, as used at the Royal Botanic Garden Edinburgh) Code 3 of 9 encoding (peel-off pre-printed herbarium labels)
Can I collect inventory data for BG-BASE using a hand-held device?
Yes. Kings Park and Botanic Garden (Perth, Australia) and the Royal Botanic Garden Edinburgh have worked with BG-BASE, Inc. to develop a system for processing PLANTS and PROPAGATIONS data and moving it into BG-BASE once it has been read into a barcode-enabled hand-held device.
The process is simple: After the hand-held device has been properly programmed, it asks the user his/her initials and today's date, both of which are stamped on each record input through the system. After the appropriate barcode has been entered using the built-in barcode reader (or entered manually if a barcode is not available on a particular label), the user is prompted for all relevant information to update the location, condition, or number of plants. When one record has been completed, the user scans the next barcode and repeats the process. As many PLANTS or PROPAGATIONS records can be input as desired, up to the limit of the memory of the hand-held device (normally, they will hold ca. 500-1000 records). The hand-held device is then returned to a base station where its contents are downloaded onto the system, and a program is run against this downloaded file to check for any errors.
Once the data are judged to be clean, the program uses them to automatically update the appropriate records in the PLANTS or PROPAGATIONS tables. The next person using the hand-held device inputs his/her initials and today's date, and the process is repeated.
How can I display images from BG-BASE?
Managing digital images in the database is a two-step process. First, you must acquire, download, purchase, scan, or create the digital images themselves. If you wish to capture existing images (color photographs, black and white photographs, drawings, maps, etc.), you can do so by using a flat-bed scanner, a hand-held scanner, a slide scanner, or a digital camera. Or, you can use the services of a photographic studio or drugstore to put your slides onto a Kodak PhotoCD®.
Once you have digitized your images, you must save them in one of the supported image file formats (.BMP, .DIB, .GIF, and .JPG) and store them on your hard disk, preferably in a subdirectory of their own (BG-BASE assumes that images are stored in the IMAGES subdirectory directly beneath the BGBASE subdirectory, although this is a user-configurable option that can be changed). If you are using BG-BASE on a network, be sure to store them on the fileserver so that everyone has access to them.
The second step is to create a record in the IMAGES table for each digitally stored image (this table also stores records for images that have not been scanned). In addition to the fields that store the file name for where the digital image can be found, records in this table can be linked to the ACCESSIONS, BRUS, COLLECTORS, CONSERVATION AREAS, COUNTRIES, LOCATIONS, NAMES, PLACES, PLANTS and SPECIMENS tables. Once the IMAGES records are created, you can view relevant images from any of these tables by using one of the softkeys (shift-F10).
How does BG-BASE handle geographic information?
BG-BASE handles the complexities of the geographic hierarchy through a series of database tables and fields, managing information ranging in scale from continents down to specific localities.
The collecting localities for wild-origin living or preserved material can be mapped from data exported from BG-BASE using one of the many shareware mapping utilities.
See the features document for further information on geography.
How does BG-BASE handle taxonomic and nomenclatural information?
BG-BASE handles the complexities of the taxonomic hierarchy through a series of database tables and fields, managing information ranging from kingdom down to sub-form and cultivated taxa. See the features document for further information on nomenclature and taxonomy.
How does BG-BASE handle synonymy?
BG-BASE handles the many-to-many relationships involved in scientific synonyms by linking one record in the NAMES table to as many other records as necessary. Each record is indexed under the "accepted" name as well as under each variant (full synonym, pro parte synonym, orthographic variant, manuscript name, invalid name, etc.). See the features document for further information on synonymy.
How does BG-BASE handle typification?
Each record in the SPECIMENS table can be linked to as many scientific names as it typifies. This a many-to-many relationship (many type specimens per taxon, or many taxa typified by a particular specimen) to be set up between specimens and names. From the NAMES table, you can display all types of a name by pressing a softkey.
Can BG-BASE track genotypes and genetic lineages as well as accessions?
Yes. The ACCESSIONS table in BG-BASE can be used to track individual genotypes or collections of genotypes, depending upon what is appropriate in that particular circumstance. The DNA SEQUENCES tablelinks to the ACCESSIONS and NAMES tables so that sequence data can be linked at both levels.
What are Server Deployment Packs (SDP's)?
You need to have the Server Deployment Packs (SDP's) if you wish to have BG-BASE on a network. If you already have BG-BASE networked it is, technically speaking, your copy of OpenInsight that is networked, and not your copy of BG-BASE (although the two go hand-in-hand). You can still give as many users access to BG-BASE as you want. The SDP's control how may of those users can be logged in at any one time. This is a licensing restriction put in place by Revelation Software, Inc., not by us.
© Copyright BG-BASE, Inc., 1997-.
Last updated: 14 April 2004