Databases and Systems

107
For the purposes of the rest of this article, we assume that the system is
implemented using an object-relational engine, such as Illustra/Informix Universal
Server or Oracle version 8. With a straightforward design approach, each class/entity
would be represented as a table, while associations between classes would be
represented as "bridge" tables with foreign keys referencing one or more entity
tables. Often subclasses might need to be derived from a parent class, to store
additional, specific information.
With highly heterogeneous data such as is typical of NS data, this approach
eventually yields a significant number of classes as well as a complex class hierarchy.
More important, the bridge tables can get potentially unmanageable because, with M
classes, there are potentially M C2 bridge tables for binary relationships alone
(ignoring the possibility of recursive relationships). We must therefore seriously
consider ways of simplifying the schema.
The Object Dictionary Approach
A well-known approach, which we term the Object Dictionary (OD) approach, solves
the problem partially. (This technique, we believe, was pioneered by Tom Slezak's
team in the course of the Lawrence Livermore chromosome 19 mapping project (11).
It was subsequently adopted in production systems such as version 5 of the Human
Genome Database (12), as well as in DNA Workbench, a package to manage
physical mapping data within a chromosomal region (13).) In the OD approach, all
classes within the system are children of a parent "Object" class. The Objects table
contains information on every "object" (class/subclass instance) within a system, with
each row typically containing at least the following information: a machine-generated
ID, object name and object class ID. (The last is a foreign key into a Classes table.)
The details of a particular object are found in a class-specific table whose structure is
specific to the object's class or subclass, and which is related one-to-one to the
Objects table.
One advantage of the OD approach is that, because all object names and
definitions are stored in one place, one can create supporting tables (e.g., synonym /
keyword tables) to build search tools that have some semblance of intelligence.
(Synonyms occur very commonly in NS data: the terms 5-HT, serotonin and 5hydroxy-tryptamine
refer to the same neurotransmitter molecule.) It is unreasonable
to insist that most users of an NS database specify the class of object along with the
object name in a query, when the name is often unique enough. (For example,
"muscarinic" can only refer to a receptor class, and amacrine refers only to a class of
retinal neurons.) Only if the term specified by the user is ambiguous is it necessary
for the system to display all likely candidates, and force the user to select one.
The OD approach is particularly useful for managing binary associations. Instead
of numerous bridge tables for each pair of object classes, we have a single
Associations table with at least three columns: Object ID 1, Object ID 2, description
of relationship. (In an archival database that gathers information from multiple
sources, there is typically a fourth column, a citatiodreference.) Only a single